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-16 22:51 UTC ====================================================================== Summary: Standardize gzip(1) cli interface instead of adding it to compress(1) ======================================================================
---------------------------------------------------------------------- (0006754) nrk (reporter) - 2024-04-16 22:51 https://www.austingroupbugs.net/view.php?id=1827#c6754 ---------------------------------------------------------------------- > and it's just one implementation had already implemented gzip compression in the `compress` utility in the current form AFAIK, that implementation is openbsd: https://man.openbsd.org/compress.1 But openbsd also provides gzip(1), with the familiar -0..9 cli flag for compression level: https://man.openbsd.org/gzip.1 And so IMO, deciding to add gzip support to compress(1) - which is followed by a single implementation - instead of standarizing gzip(1) which is followed by nearly all implementation is very poor and is leading to many of the concerns outlined above. > the `compress` utility can (if I didn't interpret it wrong) report "unsupported" for some combinations of the options. It may, but my point was about poor and confusing interface. A flag doing one thing in one case and something completely different in another is usually not good design. Furthermore, consider the hassle when trying to look through the manpage. Currently I can do `man gzip` and only see gzip(1) specific options or `man compress` and only see compress(1) specific options. Merging gzip and lzw into a single utility means the documentation will be cluttered with both even when I'm only looking for one. > the current draft 4 has passed a stage where we can make normative changes to, so we might have to settle with an application usage or rationale section That's unfortunate. If gzip(1) cannot be added, can the changes to compress(1) be reverted at least? > some linux distros don't ship `pax` by default, but instead `cpio` and `tar`. This is one more reason why I believe the compress(1) change should be reverted. gzip(1) is so ubiquitous that the chances that people start using compress(1) for it is HIGHLY unlikely - especially when you consider the "Hurdles for script authors" issues I raised above. As such, I would not be surprised at all if distributions continue to not ship compress(1) or if compress(1) implementations simply not add gzip support (aside from openbsd which already has it). And so a very likely outcome is a more complicated compress(1) specification which benefits no one. 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 ======================================================================
