Make the builtin `extract` and `archive` plugins handle `*.tar` formats better #1548

xfzv · 2024-08-24T15:21:04Z

What system are you running Yazi on?

Linux X11

What terminal are you running Yazi in?

kitty 0.35.2

`yazi --debug` output

Yazi
    Version: 0.3.1 (69c20d4 2024-08-24)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.1 (69c20d4 2024-08-24)

Emulator
    Emulator.via_env: ("xterm-kitty", "")
    Emulator.via_csi: Ok(Kitty)
    Emulator.detect : Kitty

Adapter
    Adapter.matches: Kitty

Desktop
    XDG_SESSION_TYPE: Some("tty")
    WAYLAND_DISPLAY : None
    DISPLAY         : Some(":0")

SSH
    shared.in_ssh_connection: false

WSL
    /proc/sys/fs/binfmt_misc/WSLInterop: false

Variables
    SHELL              : Some("/bin/zsh")
    EDITOR             : Some("nvim")
    VISUAL             : Some("nvim")
    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       : No such file or directory (os error 2)
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.2
    magick           : 7.1.1-25
    fzf              : 0.53.0
    fd               : 10.1.0
    rg               : 14.1.0
    chafa            : No such file or directory (os error 2)
    zoxide           : 0.9.4
    7z               : 16.02
    7zz              : No such file or directory (os error 2)
    jq               : 1.7.1


--------------------------------------------------
When reporting a bug, please also upload the `yazi.log` log file - only upload the most recent content by time.
You can find it in the "/home/xfzv/.local/state/yazi" directory.

Did you try the latest nightly build to see if the problem got fixed?

Yes, and I updated the debug information above (yazi --debug) to the nightly that I tried

Describe the bug

When extracting a tar.gz archive that contains a single file in it (no directory):

 archive.tar.gz
└──  binary

with default extract opener

yazi/yazi-config/preset/yazi.toml

Line 49 in 69c20d4

{ run = 'ya pub extract --list "$@"', desc = "Extract here", for = "unix" },

Here's what happens:

A directory named after the archive is created (archive)
An archive.tar file is created inside archive directory
After pressing Enter to extract the archive.tar file, another directory called archive is created
Inside this archive directory, we finally have binary
binary file permissions are not preserved (644, is actually 755)

The final file hierarchy structure:

 .
├──  archive                               # 1. first directory created
│   ├──  archive                           # 3. second directory created
│   │   └──  file                          # 4. binary
│   └──  archive.tar                       # 2. second archive created
├──  archive.tar.gz                        # 0. original archive

I'm aware this is the default 7z behavior (can reproduce with 7z x archive.tar.gz)
but this is really not convenient. With:

% tar -xvz archive.tar.gz

the binary is directly extracted to the current directory and permissions are preserved.

Any chance the extract feature could be more optimized? In this case, tar is definitely more suitable than 7z.

Minimal reproducer

Download this tar.gz file
Without any ~/.config/yazi directory, reproduce steps detailed in Describe the bug to extract the tar.gz archive and observe the final file structure
Now try the following instead:

% tar -xvz viddy-v1.0.1-linux-x86_64.tar.gz
viddy

% ls -al viddy
-rwxr-xr-x 1 xfzv users 8.2M Aug 24 16:08 viddy

% lsd --tree
 .
├──  viddy
└──  viddy-v1.0.1-linux-x86_64.tar.gz

The binary is extracted to the current directory
Permissions (755) are preserved

Anything else?

No response

The text was updated successfully, but these errors were encountered:

sxyazi · 2024-08-25T13:41:05Z

Any chance the extract feature could be more optimized? In this case, tar is definitely more suitable than 7z.

I think this is possible, but I have a few questions/concerns:

What about Windows users?
Is tar available on all platforms (such as NixOS as well)? Do we need to add it to Yazi's dependency list?
Can tar provide an efficient archive preview feature? We need to make sure that the content users preview matches the content that's ultimately extracted. 7zip only previews the outer structure, so if we use 7zip to preview tar extractions, it might confuse users.
What if the user has only installed tar or 7zip (considering both extraction and preview)?

xfzv · 2024-08-25T15:56:28Z

* What about Windows users?

After a quick research, it doesn't seem that tar is natively available for MS Windows. Found Tar for Windows but it's completely out-of-date (2003) so it's probably not relevant. Correct me if I'm wrong, maybe a maintained port exists.

Edit: tar is actually available out-of-the-box on MS Windows, see #1548 (comment)

* Is tar available on all platforms (such as NixOS as well)? Do we need to add it to Yazi's dependency list?

It seems that it's available as gnutar for NixOS and with brew too.

* Can tar provide an efficient archive preview feature? We need to make sure that the content users preview matches the content that's ultimately extracted. 7zip only previews the outer structure, so if we use 7zip to preview tar extractions, it might confuse users.

Using -t, --list:

man 1 tar

-t, --list
List the contents of an archive. Arguments are optional. When given, they specify the names of the members to list.

Using the provided tar.gz example:

% tar -tf viddy-v1.0.1-linux-x86_64.tar.gz
viddy

Note that unlike 7z, it only works for tar archives:

% tar -tf test.zip
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

What if the user has only installed tar or 7zip (considering both extraction and preview)?

Considering both tools can preview/extract, just use the one installed I guess? ~~Since tar doesn't seem to be available on MS Windows (again, I might be wrong), 7z would be the only option for Windows users.~~

Edit: tar is actually available out-of-the-box on MS Windows, see #1548 (comment)

veltza · 2024-08-26T11:39:47Z

Windows 10 and 11 come with tar.

Links

xfzv · 2024-08-26T12:28:13Z

Windows 10 and 11 come with tar.

Links

* [The Windows Process Journey — tar.exe (BSD tar Archive Tool)](https://medium.com/@boutnaru/the-windows-process-journey-tar-exe-bsd-tar-archive-tool-d307a4412c46)

* [How to extract .tar.gz files on Windows 11](https://pureinfotech.com/extract-tar-gz-files-windows-11/)

Thanks for the info, I didn't know that. I've just tried on a Windows 10 VM, -t, --list seems to work just fine:

% C:\Users\User\Downloads> tar -tf viddy-v1.0.1-linux-x86_64.tar.gz
viddy

sxyazi · 2024-08-26T15:36:58Z

Thanks for the info! I think it's worth a try.

Is anyone interested in implementing it? If it's simple enough and doesn't add too much maintenance overhead (let's say <100 lines), I'd be open to accepting a PR.

The code for the extract plugin is here: https://github.com/sxyazi/yazi/blob/main/yazi-plugin/preset/plugins/extract.lua

DirkFi · 2024-08-28T19:24:26Z

Hi, @xfzv .
Can you tell a bit more about steps to reproduce? I'm using Arch Linux and have deleted the ~/.config/yazi to use the default extract opener. But heres what happened: I only gets a dir called viddy-v1.0.1-linux-x86_64 with a file viddy-v1.0.1-linux-x86_64.tar in it. And the state in the right corner shows the task is processing 99%.
Check out here: reproduce preview.

Update: After restarting my computer, the 99% disappeared, but the dir still looks the same.

xfzv · 2024-08-28T19:59:24Z

@DirkFi I've just tried on my Arch Linux install and it behaves as I mentioned in OP, the extract task isn't stuck and I eventually have the viddy binary.

And the state in the right corner shows the task is processing 99%.

If you manage to get the task stuck at 99% again, open the task manager and press Enter to see more details about it.

~~I assume you do have tar installed considering it's in the base group?~~ Edit: Sorry, I meant p7zip

Can you try with another tarball maybe?

Which version of yazi are you using? As far as I'm concerned:

% yazi -V
Yazi 0.3.2 (ddb8ce5 2024-08-28)

Anything in ~/.local/state/yazi/yazi.log?

DirkFi · 2024-08-28T22:23:37Z

@xfzv

~~I did not see any useful info in log file. My version is 0.3.1 and i also tried to install from the source code which was just now updated to 0.3.2 but still got similar results.~~

~~And, yes, I have p7zip installed and can run 7z command. Maybe I need to try another tarball.~~

Sorry about the misunderstanding, seems that I misunderstands your point. The image I shared with you actually reproduced the problem but I did not notice that and thought it was not the issue. Right now I understand that the issue is for tar.gz file it needs to unzip twice to get the original file and create some redundant dirs.

BTW, how to open the task manager inside Yazi?

xfzv · 2024-08-29T04:45:11Z

BTW, how to open the task manager inside Yazi?

With w:

https://github.com/sxyazi/yazi/blob/main/yazi-config/preset/keymap.toml#L146-L147

DirkFi · 2024-09-01T00:32:39Z

Fix in PR1583.

xfzv added the bug Something isn't working label Aug 24, 2024

sxyazi added enhancement New feature or request and removed bug Something isn't working labels Aug 25, 2024

sxyazi added the waiting on op Waiting for more information from the original poster label Aug 25, 2024

github-actions bot removed the waiting on op Waiting for more information from the original poster label Aug 25, 2024

sxyazi added the good first issue Good for newcomers label Aug 26, 2024

sxyazi changed the title ~~ya pub extract - 7z creates useless complex file structure~~ Make the builtin extract and archive plugins handle *.tar formats better Aug 26, 2024

DirkFi mentioned this issue Sep 9, 2024

feat: make the builtin extract plugin support compressed tarballs (*.tar.gz, *.tar.bz2, etc.) #1583

Merged

sxyazi closed this as completed in #1583 Sep 14, 2024

xfzv mentioned this issue Sep 28, 2024

enter_archives doesn't behave like recent upstream yazi improvement hankertrix/augment-command.yazi#4

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make the builtin `extract` and `archive` plugins handle `*.tar` formats better #1548

Make the builtin `extract` and `archive` plugins handle `*.tar` formats better #1548

Make the builtin extract and archive plugins handle *.tar formats better #1548

Make the builtin extract and archive plugins handle *.tar formats better #1548

Comments

What system are you running Yazi on?

What terminal are you running Yazi in?

yazi --debug output

Did you try the latest nightly build to see if the problem got fixed?

Describe the bug

Minimal reproducer

Anything else?

Make the builtin `extract` and `archive` plugins handle `*.tar` formats better #1548

Make the builtin `extract` and `archive` plugins handle `*.tar` formats better #1548

`yazi --debug` output