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
======================================================================
