A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1827 ====================================================================== Reported By: nrk Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1827 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: NRK Organization: User Reference: Section: compress(1) utility Page Number: n/a Line Number: n/a Final Accepted Text: ====================================================================== Date Submitted: 2024-04-15 03:23 UTC Last Modified: 2024-04-17 00:32 UTC ====================================================================== Summary: Standardize gzip(1) cli interface instead of adding it to compress(1) ======================================================================
---------------------------------------------------------------------- (0006758) nrk (reporter) - 2024-04-17 00:32 https://www.austingroupbugs.net/view.php?id=1827#c6758 ---------------------------------------------------------------------- > Standardizing a single frontend for various compression formats makes more sense than standardizing a separate utility for each format. I fail to see how it "makes more sense", especially in the face of all the issues I've raised (none of which has been countered). But let's imagine that a single monolithic tool becomes standard. Now let's imagine that there's a script/program that needs to decompress both X and Y file. Something like: uncompress -m X ... uncompress -m Y ... Now if my system's uncompress(1) only support X but doesn't support Y this will not work. And if I try to replace my system's uncompress(1) with a separate implementation which supports Y but doesn't support Z (which may be needed elsewhere) then what's the solution to this? Continually keep symlinking uncompress(1) to whatever implementation happens to work for the moment? Having separate compression utility that deal with separate formats avoids such issues. I can have gzip(1), bzip2(1), zstd(1) etc, all installed at once. I can even use pigz(1) and symlink it to gzip(1) (which I do in my system) since it's a compatible alternative which also has multi-threaded compression. A standalone tool like pigz(1) would not be able to exist - and be easily used system wide by simply symlinking it to gzip(1) - if the convention was a single monolithic tool for all algorithm. And what happens if someone comes up with a new algorithm? Convention of a single monolithic tool forces him to either go add his algorithm to this one monolithic tool or to fork it. The current convention of different tool allows him to just release his own tool without worrying about getting it into the monolithic compress(1) implementation. Moreover, people who use that tool do not have to worry about whether their system's monolithic compress(1) supports it or not, because each tool can co-exist separately. And so I don't think a monolithic tool "makes sense", it is a direct downgrade that: * Goes against existing convention and practices. * Makes it impossible for a user to pick and choose which utility and/or specific implementation they want to use. * Makes it difficult for implementations to provide standalone tool focusing on a single format. * Makes a mess out of the cli options where different algorithms have different parameters. * Makes the manpage and documentation either a clustered mess or a small subset which doesn't offer any way to tune algorithm specific params. Issue History Date Modified Username Field Change ====================================================================== 2024-04-15 03:23 nrk New Issue 2024-04-15 03:23 nrk Name => NRK 2024-04-15 03:23 nrk Section => compress(1) utility 2024-04-15 03:23 nrk Page Number => n/a 2024-04-15 03:23 nrk Line Number => n/a 2024-04-15 03:24 nrk Issue Monitored: nrk 2024-04-16 05:57 dannyniu Note Added: 0006752 2024-04-16 05:58 dannyniu Note Edited: 0006752 2024-04-16 18:39 steffen Note Added: 0006753 2024-04-16 22:51 nrk Note Added: 0006754 2024-04-16 23:03 nrk Note Added: 0006755 2024-04-16 23:32 oguzismailuysalNote Added: 0006756 2024-04-17 00:10 steffen Note Added: 0006757 2024-04-17 00:32 nrk Note Added: 0006758 ======================================================================
