Re: resolution of the tar -I issue
On Thu, 11 Jan 2001, Sam Vilain wrote:
> Heck... why not? -Z on its own will be an error, unless people are
> very unlucky. And this way it makes a lot more sense and this problem
> doesn't arise again. Define -z is -Z1 and -zz is -Z2 even and make it
> look planned :).
> I only suggest stealing -Z because no-one in their right mind would
> use compress except in small places where they have to ... I bet the
> feature was just added for completeness anyway.
To you, compress support is a small feature. To anyone who has to use tar on
a closed-source Unix, built-in compress support in gnu tar is the best thing
since /dev/bread[1]. Since gtar does see a lot of use on other Unices, and
*not* just on GNU/Linux, the tar maintainers have to keep sight of the big
picture, and just as making GNU tar incompatible with previous versions should
be considered unacceptable, making Debian's tar package incompatible with GNU
tar as distributed on other platforms is equally unacceptable.
Incidentally, has anyone else here noticed that recent versions of libz are
in fact capable of uncompressing 'compress'ed files? That means you can run
'tar zxvf program-0.1.tar.Z', and it will automatically identify the
compression type and uncompress the archive for you. So the only reason the
-Z option is still necessary is for the creation of .Z archives... if there
were consensus that creating .Z files was no longer useful, -Z could be reused
for bzip2, and -z could be used for gzip and compress. We are, of course, a
long way from such consensus, but it's fun to speculate. :)
Steve Langasek
postmodern programmer
[1] What do you mean, there's no block device major # reserved for food
groups? Outrageous!
Reply to: