A NOTE has been added to this issue. ====================================================================== https://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 07:47 UTC ====================================================================== Summary: Standardize gzip(1) cli interface instead of adding it to compress(1) ======================================================================
---------------------------------------------------------------------- (0006761) nrk (reporter) - 2024-04-17 07:47 https://austingroupbugs.net/view.php?id=1827#c6761 ---------------------------------------------------------------------- > Extending an existing utility with basic support for an additional input format is less demanding Both the gzip file-format and the underlying algorithm (DEFLATE) are *entirely different* to LZW. LZW builds up a dictionary on the go whereas DEFLATE is a combination of Huffman code + LZ77. Adding DEFLATE support to existing LZW implementation would be just as much work as writing a DEFLATE implementation from scratch because they share almost *nothing in common*. Most other compression algorithms (bzip2, zstandard etc) in use are in similar boat where they are all vastly different to one another. Only exceptional case where a monolithic tool would save work is for xz, lzip and 7z; all of which uses a variant of LZMA. So in cases where an implementation wants to support both algorithms, the current state of compress(1) is not "less demanding" and saves them no work. Not to mention, any implementation that wants to be useful in practice will need to ship gzip(1) anyways. So in practice, it's *more* work, not less. (This is all ignoring the glaring fact that gzip has multiple implementations and is already shipped nearly everywhere. So in practice, standardizing gzip(1) would've required *no work* - both for developers and users/script-authors). > as if POSIX mandates the exclusion of individual compression utilities, which is not true It doesn't exclude it but it doesn't standardize it either, despite being the de facto standard. And it's hostile towards developers who want to provide standalone tools. Currently if I want to provide a posix-compliant compress(1) tool, I only need to worry about LZW. Or if gzip(1) was standardized, and I wanted to provide posix-compliant gzip(1) I'd only need to worry about DEFLATE. But in the current draft, implementating a posix-compliant compress(1) requires me to both implement LZW and DEFLATE. > This is not a good place to advertise our toy programs. I'm not sure why you think pigz(1) is a toy program. It's written and maintained by Mark Adler (one of the two original authors of the gzip format), is available in repos of many distros and some distros also offer using pigz(1) as a drop-in replacement for gzip(1) (such as gentoo via app-alternatives/gzip). This is the type of customizability and control the user would lose if instead everything was crammed into a single binary. --- But in any case, putting all other arguments aside, what is unarguable is that standards that are not well adopted are next to useless. And by going for a monolithic compress(1) tool, POSIX is heading in a direction that is opposite of what the existing practice is. And in doing so, it's asking people (both system developers and users/script-authors) to put in work in order to be compliant with the spec rather than making the spec compliant with existing practices; which is not a good direction to be heading in, if wide adoption is to be desired. 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 2024-04-17 01:36 larryv Note Added: 0006759 2024-04-17 06:16 oguzismailuysalNote Added: 0006760 2024-04-17 06:18 oguzismailuysalNote Edited: 0006760 2024-04-17 06:19 oguzismailuysalNote Edited: 0006760 2024-04-17 07:47 nrk Note Added: 0006761 ======================================================================
