The following issue has been SUBMITTED. ====================================================================== 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-15 03:23 UTC ====================================================================== Summary: Standardize gzip(1) cli interface instead of adding it to compress(1) Description: As a resolution to https://www.austingroupbugs.net/view.php?id=1041 the gzip/deflate algorithm was added to compress(1) tool.
I believe standardizing the gzip(1) interface would've been the correct decision and adding gzip format to compress(1) will create a bunch of practical issues which I'll outline below. Hurdles for script authors -------------------------- gzip(1) is ubiquitous and is shipped with almost every distribution. Whereas compress(1) is often not installed by default on many systems. If gzip(1) is standardized, the most existing scripts that are using gzip will automatically become compliant with next POSIX edition. On the other hand adding gzip to compress(1) means such scripts will need to be edited to use compress(1) in order to avoid non-posix dependency. But doing so will result in such scripts no longer working on older systems where compress(1) is either not available or doesn't support gzip format. Standardizing gzip(1) avoids such issues entirely. Confusing cli options --------------------- Because gzip and (ancient) compress have different file format and algorithm, many cli options which are applicable to one will not be applicable to the other. The prime example of it is the `-b` flag which has been repurposed to mean different things (max bits or compression level) depending on the algorithm used. This also deviates from *majority* of the compression tool cli interface where `-[0..9]` to indicate compression level has been the de facto standard - leading to unnecessary confusion for the users. Implementation complexity ------------------------- Currently one can implement the compress(1) utility or the gzip(1) utility as a stand-alone software without having to worry about the other. But if compress(1) also needs to support gzip format then the author now needs to implement both LZW and DEFLATE in order to be compliant. This increases the implementation difficultly - it's also against the unix philosophy of doing one thing. But even more worrying is the passage below: Other implementation-defined algorithms may be supported. If even more format are to be added in the future, then not only will that increase implementation difficultly further, it's also going to create more awkward cli option situation where parameters for a certain algorithm doesn't make sense on the other. Ultimately this will lead to the compress(1) cli either having lots of cli options being confusingly multiplexed or the options will be limited to the subset of parameters which makes sense on most/all algorithms - leading to a tool that does more than one thing, and does them poorly. Desired Action: 1. Revert the changes to compress(1) 2. Standardize a subset of gzip(1) with cli options that's known to be supported by most/all major implementations. ====================================================================== 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 ======================================================================