Dale R. Worley writes:
> What doesn't seem to exist is something that does step 2 in a general
> way. The tool that is needed is something that reads the first few
> bytes of a file, determines which compression signature is present if
> any, then processes the contents through the correct decompressor.
> Ideally, it would be programmable in something like the manner of "file"
> so that additional compression formats could be fitted into the
> framework, and it could use either a compiled-in decompression library
> (like zlib) or call an external decompression program, as necessary.
>
> Actually, I'm asking whether anybody knows whether such a tool exists
> already. It seems like a "natural" facility that somebody would have
> thought to write maybe fifteen years ago.
For a while, new options were getting added to GNU tar frequently in order
to allow you to do things like
compress -dc | tar xf -
zcat | tar xf -
bzcat | tar xf -
lzcat | tar xf -
etc., but just using the single tar invocation without (explicitly
running) an external compression program. The current ones are (in
alphabetical order in the man page, not historical order of when they
were added)
-j, --bzip2
Filter the archive through bzip2(1).
-J, --xz
Filter the archive through xz(1).
--lzip Filter the archive through lzip(1).
--lzma Filter the archive through lzma(1).
--lzop Filter the archive through lzop(1).
-z, --gzip, --gunzip, --ungzip
Filter the archive through gzip(1).
-Z, --compress, --uncompress
Filter the archive through compress(1).
--zstd Filter the archive through zstd(1).
Wow, _eight_ specific forms of compression! But a newer functionality
in GNU tar is
-a, --auto-compress
Use archive suffix to determine the compression program.
and something like that (apparently also looking at the file header)
is now the default.
It's weird to me to imagine having all of that functionality in grep,
but maybe all of the functionality that was put into tar for this could
become a separate standalone program?
