Extract specific files/folders from archives

[roland-5]

Can ouch do this now? I didn't see information about in man or here.

[figsoda]

AFAIK it doesn't do this now, what do you think about having a flag that accepts a glob pattern for the decompress subcommand?

[marcospb19]

Interesting suggestion, like Figsoda suggested, we can use a glob, regex or fzf filter, it would be kinda simple to implement too.

[roland-5]

Personally I'm note sure what best solution is, but I was thinking about something like:

ouch list test.tar.gz
Archive: /home/roland/test.tar.gz
├── vacation
│  ├── Portugal
│  │  └── 20220824
│  │     ├── videos
│  │     │  ├── video1.mp4
│  │     │  ├── video2.mp4
│  │     │  ├── video3.mp4
│  │     │  ├── video4.mp4
│  │     │  ├── video5.mp4
│  │     │  ├── video6.mp4
│  │     │  ├── video7.mp4
│  │     │  ├── video8.mp4
│  │     │  ├── video9.mp4
│  │     │  └── video10.mp4
│  │     ├── photos
│  │     │  ├── a.jpg
│  │     │  ├── b.jpg
│  │     │  ├── b2.jpg
│  │     │  ├── b3.jpg
│  │     │  └── c.jpg
│  │     ├── gifs
│  │     │  ├── 001.gif
│  │     │  └── 001.gif
│  │     ├── gifs-second
│  │     │  ├── 003.gif
│  │     │  └── 004.gif
│  │     ├── files
│  │     │  └── todo.md
│  │     ├── message_1.json
│  │     └── message_2.json
│  └── wheretoflynext.odt
├── todo.md
└── cooking
   └── recipe.md

What if I want folder videos with it's all movies from 20220824 folder? What if I want only photos (or files?) started with letter b?

Would that be somehow logical?

ouch decompress --data vacation/Portugal/20220724/videos --data b*.jpg --data todo.md --data *.gif test.tar.gz

But then again. Would they decompress with the same path as they in archive? If not, what about files with the same name and extension? For me it's not the problem, but what if someone have archive with file that is deep nested like folder/folder/folder/folder/folder/folder/folder/folder/folder/folder/folder/folder/folder/file - It would be one damn file and million folder in folder directories.

[mrzv]

I came here to file the same feature request. Argument-wise, in the spirit of simplicity, why not make it:

ouch decompress test.tar.gz vacation/Portugal/20220724/videos cooking/recipe.md

Basically, only one archive can be decompressed at a time, and any argument after the archive name is interpreted as a path inside the archive to extract.

[bew]

An alternative syntax could be to consider everything after -- be the files (or pattern of files) to decompress:

ouch d foo.zip bar.zip -- 'some-dir/*.md' README.md

So this still supports decompressing multiple archives

[polarathene]

The -- suggestion would be ideal (along with clear documentation example).

For the other concern with nested folders unzip has a -j "junk paths" flag that strips the parent paths of the files/folders you target for extraction. They likewise have an -x exclusion flag for the opposite functionality this issue requests.

Another common flag to use with this is functionality in tar is -C for changing the extraction directory. You can then use curl / wget to download an archive file (like from GH releases) and output that to stdout piped into tar like | tar -xz -C /usr/local/bin --no-same-owner some-bin-name, which extracts the target file to /usr/local/bin/some-bin-name, the --no-same-owner ignores the archives owner/group values and uses the current users instead (GH release seem to be 1001:127 when produced by CI?) whilst keeping the executable bit +x if present.

[marcospb19]

Good input, thank yall.

Can someone pls try to figure out if we can get all the files after a -- with clap?

We depend on its support to it. Otherwise we'll have to go with something else, like decompressing one archive per invocation and having the rest of the arguments be the filter.

But I honestly don't remember the last time I had to decompress a bunch of archives all at once, I do one at a time.

A tiny problem with just supporting one at a time is that we'd give up on parallel decompression, well, you can still run ouch in two different shells and have the same effect, so idk, I'm leaning towards usability over (theoretical) performance.