Stop yazi from opening extracted directory in GUI file Manager

[himanshugoswamiii]

Hello, I'm using yazi on my remote linux machine, which i mostly access using ssh with Zellij
Whenever i try to extract a .tar.gz file using <Enter> it gets stuck at 99%

When i did the same thing using TigerVNC, I realised that yazi actually opens a GUI file explorer after extraction (which is not possible in case of ssh)

This can be confirmed with this msg as well:

So i decided to add these lines to my yazi.toml file:

[open]
prepend_rules = [
	# Only Decompress and Unarchive. Do not open
	{ mime = "application/{,g}zip", use = [ "extract" ] },
	{ mime = "application/x-{tar,bzip*,7z-compressed,xz,rar}", use = [ "extract" ] }
]

But somehow yazi is still trying to open the extracted files which i do not want.

Why would i like to open my extracted files in a GUI file-manager when I'm already using yazi (a file manager)

[sxyazi]

You can click <enter> on the task to inspect what error occurred while running the command, also do a yazi --debug maybe help

[himanshugoswamiii]

I tried to inspect it and it is filled with this :

❯ yazi --debug

Yazi
    Version: 0.3.3 (7222e17 2024-09-20)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.3 (7222e17 2024-09-20)

Emulator
    Emulator.via_env: ("xterm-256color", "")
    Emulator.via_csi: Ok(Unknown([]))
    Emulator.detect : Unknown([])

Adapter
    Adapter.matches: Chafa

Desktop
    XDG_SESSION_TYPE           : None
    WAYLAND_DISPLAY            : None
    DISPLAY                    : None
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: true

WSL
    WSL: false

Variables
    SHELL              : Some("/bin/bash")
    EDITOR             : Some("nvim")
    VISUAL             : None
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })
    block  : Some(Opener { run: "${EDITOR:-vi} \"$@\"", block: true, orphan: false, desc: "$EDITOR", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : 2.7
    ZELLIJ_SESSION_NAME: None
    Zellij version     : 0.40.1

Dependencies
    file             : 5.33
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: No such file or directory (os error 2)
    magick           : No such file or directory (os error 2)
    fzf              : 0.46.1
    fd               : 8.7.0
    rg               : 13.0.0
    chafa            : No such file or directory (os error 2)
    zoxide           : No such file or directory (os error 2)
    7z               : 16.02
    7zz              : No such file or directory (os error 2)
    jq               : 1.6

[himanshugoswamiii]

After reading through the docs and some reddit posts, i found the issue.

The issue was mime-type:

❯ file -i sdsdsd_20240917075618.tar.gz
sdsdsd_20240917075618.tar.gz: application/x-gzip; charset=binary

In this Oracle Linux Distribution, the mime-type is still being used as application/x-gzip, while on my personal linux machine it is application/gzip

yazi doesn't have any handling for application/x-gzip mime-type in [open] rules in file : https://github.com/sxyazi/yazi/blob/shipped/yazi-config/preset/yazi.toml

So, i needed to add this to my config:

prepend_rules = [
	# Archive
    { mime = "application/x-gzip", use = [ "extract", "reveal" ] },
]

[sxyazi]

Ah I'm glad to see the issue has been resolved.

It was quite a headache since some versions of file(1) would include x-, i.e. application/x-gzip, while others wouldn't, just application/gzip.

Yazi already has rules for handling application/gzip, but unfortunately, not for the x- version:

yazi/yazi-config/preset/yazi.toml

Line 70 in 7c445ce

{ mime = "application/{,g}zip", use = [ "extract", "reveal" ] },

The good news is that Yazi 0.4 will try to address this issue at its core.

The x- prefix will be completely deprecated, so even if file(1) returns a version with x-, it'll be converted to the version without it. This way, users can maintain their rule sets more easily without having to worry about whether there's an x- or not.

[himanshugoswamiii]

Yes, I saw the v0.4 ToDo-List
I actually thought that you'll stop handling x- mime-type after v0.4 by default 😆
But now i understand what you mean