| Summary: | gzcat does not actually perform gzip -dc for gzip-1.3.11 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Gil Kloepfer <gbz> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
*** This bug has been marked as a duplicate of bug 175279 *** |
The ebuild for gzip installs the symlink for gzcat, but gzcat does not actually perform "gzip -dc {file}" but rather simply runs gzip. Reproducible: Always Steps to Reproduce: 1. Compress a file text with gzip (creating example-file.txt.gz) 2. gzcat example-file.txt 3. also try gzcat example-file.txt.gz Actual Results: 2. gzcat: example.file.txt: No such file or directory 3. gzcat: example.file.txt.gz already has .gz suffix -- unchanged Expected Results: in both cases, the uncompressed text file should have been displayed This behavior for gzcat is actually somewhat controversial. FreeBSD, for example, defines the behavior for gzcat that I am expecting. This would, in my opinion, be the only reason one would create a symlink/command called "gzcat." However, an examination of the source for gzip-1.3.11 gzip.c lines 411-428 appears to imply that this is not the "GNU standard" behavior. The right fix, in my opinion, would be to implement the FreeBSD-style behavior by defining GNU_STANDARD=0 in the CFLAGS for the gzip ebuild. It would also be acceptable to implement this via a USE flag (gnustandard, for example) that would allow the gzcat symlink and "non-GNU-standard" behavior to be restored if -gnustandard was given.