Hello,
I don't have the time to check your proposal in details.
But I support your idea.
The fact is that most of the time typing unpack is not faster
than typing the specialized command after reading the name of the archive
like `unzip archive.zip`.
But an archive may have a wrong extension in its name,
and unpack can detect that and apply the correct decompression algorithm.
Moreover, for all the persons that have to code some Bash scripts
(or Python scripts or PHP scripts, etc. if you do a lib version of pack/unpack)
with a loop on archives for decompressing them,
it is way smarter to call a unified command unpack in the loop,
instead of having to code a `my_custom_unpack` function
that will handle the switch between archive formats.
Clearly, it is better to provide this kind of feature in coreutils or
similar foundations packages,
than to have a lot of redundant code done by many people for exactly
this same feature.
Regarding pack it could provide a default or a few defaults compression scheme.
Almost nobody has the time to follow the state-of-the-art on
compression/decompression schemes.
Pack could/should do that work for computer users.
pack dir/
should select the "best" currently available compression/decompression scheme.
pack --smallest-size dir/
should select the currently available compression/decompression scheme
that minimizes the archive size most of the time in benchmarks.
pack --fastest-compression dir/
should select the currently available compression/decompression scheme
that minimizes the archive creation time most of the time in
benchmarks.
pack --fastest-decompression dir/
should select the currently available compression/decompression scheme
that minimizes the archive unpack time most of the time in benchmarks.
Etc.
There is a need for pack/unpack. Clearly.
If it isn't in coreutils,
it is in some package that is available to most users in their distros.
Have a nice day, best regards,
Laurent Lyaudet
Le mer. 12 août 2026 à 07:22, Iván Ezequiel Rodriguez
<[email protected]> a écrit :
>
> Hi,
>
> I'd like to ask whether two small archive-oriented commands, pack and
> unpack, would be considered within the scope of GNU coreutils.
>
> The idea is to provide a simple interface for a common operation that
> currently requires knowing the particular archive/compression tool and
> its syntax:
>
> pack FORMAT SOURCE...
> unpack ARCHIVE
>
> For example:
>
> pack tar.zst src/
> pack zip file1 file2 dir/
> unpack archive.tar.zst
> unpack archive.zip
>
> pack requires the output representation to be selected explicitly,
> while unpack detects the existing representation automatically.
> The intention is not to replace tar, gzip, xz, 7z, etc., nor to
> expose all of their specialized functionality. It is to provide a
> small generic interface for the basic "pack these files" / "give me
> back these files" operations.
>
> I have a working GPLv3+ reference implementation in C (current tip
> v1.6.1):
>
> https://github.com/IRodriguez13/pack-unpack
>
> The current implementation uses libarchive deliberately rather than
> implementing archive formats itself. It currently supports tar and
> compressed tar variants, zip, 7z, and several raw compression formats.
>
> Some properties of the current implementation are:
>
> - silent successful operation, with -v for member listing;
> - relative archive member names;
> - atomic archive creation using a temporary file and rename;
> - defensive extraction against absolute paths, "..", and
> symlink/hardlink escapes;
> - explicit overwrite policies;
> - conservative metadata restoration by default, with -p for
> additional metadata;
> - regression tests for malformed and hostile archives;
> - CI testing on GNU/Linux (glibc and musl), FreeBSD, and macOS,
> including ASan/UBSan testing.
>
> I realize that the libarchive dependency may itself be an important
> consideration for coreutils, so I would especially appreciate feedback
> on whether such a dependency would be considered a fundamental obstacle,
> independently of the command interface.
>
> Before attempting to adapt the implementation to coreutils conventions
> or preparing patches, I'd like to know whether commands with this scope
> are something the project would consider in principle.
>
> There is also some historical precedent for the names pack and unpack
> in older Unix systems, although those commands had different,
> format-specific compression semantics. I mention this only as naming
> context; this proposal is not intended to reproduce their historical
> implementation or exact behavior.
>
> Feedback on the interface, scope, naming, or whether this functionality
> belongs elsewhere would be very welcome.
>
> Thanks,
>
> Iván Ezequiel Rodriguez
> [email protected]
> https://github.com/IRodriguez13/pack-unpack
>
