[lsb-discuss] question on missing zcat command
tytso at mit.edu
Fri Jan 4 13:14:23 PST 2008
On Fri, Jan 04, 2008 at 02:09:28PM -0600, George Kraft wrote:
> Apparently it was intentionally deferred from LSB 3.1.
Hmm, and the reason given is "special" --- i.e., the fact that "zcat
foo.gz" does the right and obvious thing violates the POSIX spec.
(It's supposed to decompress foo.gz.Z, or fail, if foo.gz.Z doesn't exist.)
Actually, I think Nick is wrong here. It wouldn't have caused a POSIX
compatibility issue, since zcat isn't listed as one of the commands in
section 15. So while zcat isn't compatible with POSIX (cry me a
river), it doesn't matter, because the LSB is making no statements
about zcat in the current specification.
The only thing which *is* there is the FHS, which says that *if* zcat
exists, it must be a hard link to /bin/gzip. But what happens when
you executes gzip is currently totally undefined. For example, a
valid LSB conforming distribution could have gzip check argv, and
if it was zcat, start exec /usr/bin/games/nethack. This would not
violate the LSB, since all the LSB states is that if /bin/zcat exists,
then it must be a hard link.
In fact, it would also be legal for zcat to not exist at all; which
means that LSB conforming applications would be wise not to depend on
zcat at all, since since /bin/zcat may not exist, and if it does
exist, running it may do nothing at all. (Or, start nethack :-)
Hence, it would seem to me that the right fix would be to disable the
tests that check for /bin/zcat being a hard link, and add a statement
in section 16 of the core specifications that LSB complaint
implementations are exempt from the requirements surrounding zcat as
specified in the FHS --- and that compliant applications should
probably use "gzip -d" in preference to zcat, since while zcat will
almost always exist, it is not guaranteed to exist, and even if it
does exist, what it does is not guaranteed by the LSB.
Also, BTW, it looks like the man page for gunzip in LSB 3.2 is
incomplete, in that it does not state what happens when it is asked to
decompress file with a .Z suffix. (i.e., "gunzip -d foo.Z"). Of
course, it does the right thing, but that isn't currently spelled out
in the spec.
More information about the lsb-discuss