Bug#4057: compress package install additional zcat
Yves Arrouye writes:
>Michael Meskes writes:
> > Package: compress-package
> > Version: 1.2-1
> >
> > Compiling and installing the compress source found on ftp.inria.fr
> > I get a file /usr/bin/zcat. However, gzip already install zcat in
> > /bin. I cannot see how it's useful to have both. :-)
>
>My opinion is that gzip should *not* provide /bin/zcat but rather
>/bin/gzcat (and the same for other z* tools). The /bin/zcat program
>is just *not* zcat, it also handles gzip files which the original
>zcat program cannot do. I think that we should have /bin/gzcat (or
>even /usr/bin/gzcat because gzip only should be enough in /bin) and
>have /usr/bin/zcat be a symbolic link to gzcat installed by the gzip
>package (and not an alternative as I suggested before). And most
>importantly people should refrain from using zcat in scripts when the
>intent is to gunzip something...
>
> If gzcat was provided and /usr/bin/zcat a symbolic link to it, the
>zcat link would correctly be diverted by any compress-package
>generated package and nobody would have two semantically different
>zcat commands installed by installing these packages.
IMHO:
There should be one zcat and it should always be gzip. This won't
break anything as gzip understands .Z files...
Making zcat point to compress even sometimes will definitely break
things; IME much of the Linux world has been assuming it's gzip for a
number of years. That seems unlikely to change.
compress is obsolete software; there's never any need to use it to
uncompress things. Indeed, my experience (err, on Sunos rather than
Linux, so this may not be relevant) is that gzip is much more reliable
even at uncompressing .Z files. I can't see the need to compress
things using compress either, as gzip produces smaller output, runs on
pretty much everything and is free.
--
Richard Kettlewell richard@greenend.org.uk richard@elmail.co.uk
http://www.elmail.co.uk/staff/richard/
Reply to: