Hm. Interestingly, simple-extract is one of the things that I thought we might remove at some point. That being said, there are certainly ways to improve the situation. Not sure how much work is worth it here, though. I find the function a little curious to start with. For instance, personally I always check the contents of an archive before extracting it, just to make sure the archive creates a directory, and won't litter my current working directory… I suppose we could add a -l option to support listing for all archive types as well… Then it also implicitly calls wget, which I find more surprising than useful. But maybe that's also just me.

The "one-ring-to-rule-them-all" solution, proposed might break, if different programs need different values for USE_STDIN and the like. Another thing to consider is that users might want to control which extracting program to use when multiple solutions are available, which could be done via zstyle. But I think that's all too much work for such a simple application.

Another thing is portability, since this implementation definitely requires GNU tar for many of the tar file types. That's not fantastic either. The fact that DECOMP_CMD is a string and not an array is dubious at least. I'd probably get rid of most of the magic, and have a function per file-type to dispatch to and make that function do the right thing, and put similar code structures into utility functions. But then and again I won't be the one doing it, so I guess I should stop rambling.

Getting back to the problem at hand, I think your initial suggestion would be a straight-forward, least intrusive solution. We could include something like that, without thinking too much about redesigning this thing.

just to make sure the archive creates a directory, and won't litter my current working directory

Thats why i have this function (which needs a bit of work! ^_^)

% whence -f sde
sde () {
        local f d
        test -f "${1}" || {
                echo "file missing"
                return 1
        }
        f=${1:a:q}
        d=${f:r}
        test ! -d "${d}" || {
                echo "folder ${d} already exists"
                return 1
        }
        mkdir -p "${d}"
        cd "${d}" && simple-extract "${f}"
}

especially files that have various brackets fail here so i usually use detox on those 🙈

requires GNU tar for many of the tar file types

well, i'm not sure since which version it's working but tar -xvf foo.tar{,.gz,.bz2,.xz} works here pretty much everywhere or at least on where i could test it quickly: debian+fbsd13(bsdtar)].

Anyhow, i guess that all should go into a new issue. Pushed the simple-fix for now.

i think bsdtar is kinda "better", in the sense that it uses libarchive and can unpack almost anything :)
dont really need simple-extrsct if you have bsdtar 😂

better

there might be odd behaviour anyway :----)

% find .
.
% cat << EOF > snapshots
p0/media/isos@auto-2024-11-01_07-30-1D-4W
p0/media/isos@auto-2024-11-02_07-30-1D-4W
p0/media/isos@auto-2024-11-03_07-30-1D-4W
p0/media/movies@auto-2024-11-01_07-30-1D-4W
p0/media/movies@auto-2024-11-02_07-30-1D-4W
p0/media/movies@auto-2024-11-03_07-30-1D-4W
p0/media/music@auto-2024-11-01_07-30-1D-4W
p0/media/music@auto-2024-11-02_07-30-1D-4W
p0/media/music@auto-2024-11-03_07-30-1D-4W
p0/media/tv@auto-2024-11-01_07-30-1D-4W
p0/media/tv@auto-2024-11-02_07-30-1D-4W
p0/media/tv@auto-2024-11-03_07-30-1D-4W
p0/media/tv@auto-2024-11-04_00-15-4H-1W
EOF

% find .
.
./snapshots
% zstd snapshots
snapshots            : 21.76%   (   547 =>    119 bytes, snapshots.zst)
% find .
.
./snapshots
./snapshots.zst
% tar xf snapshots
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Missing type keyword in mtree specification
tar: Error exit delayed from previous errors.
1 % find .
.
./p0
./p0/media
./p0/media/movies@auto-2024-11-02_07-30-1D-4W
./p0/media/isos@auto-2024-11-02_07-30-1D-4W
./p0/media/tv@auto-2024-11-01_07-30-1D-4W
./p0/media/music@auto-2024-11-02_07-30-1D-4W
./p0/media/tv@auto-2024-11-03_07-30-1D-4W
./p0/media/music@auto-2024-11-03_07-30-1D-4W
./p0/media/music@auto-2024-11-01_07-30-1D-4W
./p0/media/tv@auto-2024-11-02_07-30-1D-4W
./p0/media/tv@auto-2024-11-04_00-15-4H-1W
./p0/media/movies@auto-2024-11-03_07-30-1D-4W
./p0/media/isos@auto-2024-11-03_07-30-1D-4W
./p0/media/movies@auto-2024-11-01_07-30-1D-4W
./p0/media/isos@auto-2024-11-01_07-30-1D-4W
./snapshots
./snapshots.zst
% bsdtar --version
bsdtar 3.6.2 - libarchive 3.6.2 zlib/1.2.13 liblzma/5.4.1 bz2lib/1.0.8 libzstd/1.4.8

yes, those are folders and files in $PWD/p0/...

Maybe thats a feature, i called it very irritating when i stumbled over it..

simple-extract is one of the things that I thought we might remove at some point

if you want to consider that more seriously, i think a few options already packaged in debian should be evaluated:

• libarchive (ships bsdtar, which can extract from tar, zip, 7zip, etc), likely already in grml
• atool
• comprez (homepage dead)
• dtrx
• patool
• unp
• unarchive

simple-extract is one of the things that I thought we might remove at some point

if you want to consider that more seriously, i think a few options already packaged in debian should be evaluated:
[…]

I would remove it for sure. But I also don't use it myself. I think it's a little too weird (shell — even zsh — has limitations with regards to expressivity) for what it does. I know none of the alternatives you suggested. From a cursory look, patool looks promising.

simple-extract is one of the things that I thought we might remove at some point

if you want to consider that more seriously, i think a few options already packaged in debian should be evaluated:
[…]

I would remove it for sure. But I also don't use it myself. I think it's a little too weird (shell — even zsh — has limitations with regards to expressivity) for what it does. I know none of the alternatives you suggested. From a cursory look, patool looks promising.

I must admit that I don't use simple-extract myself either (mainly because it's not in my memory muscles :)).
unp usually worked fine for me, though if we have a good option that works for most/everything I'm all for it. :)
But I also don't want to stop anyone from further iterating over improving simple-extract, as long it's not getting way too complex and would warrant its own shell script or so 😀