Re: [patch] tar: short option for xz (de)compression

[Joachim Henke <free.software%gmx.com@localhost>]

On 2015-04-11 10:53, Mouse wrote:
> Okay, I'm going to make a (probably) radical suggestion here: I think
> this is a bad idea.  I'll go even further and say that I think -z is a
> bad idea too and should be removed.

While I totally understand your complains in general, I think they don't
really apply to my suggestion (see below). And they come a few decades
too late (at least regarding -z).

> NetBSD is supposed to be a Unix variant.
> 
> Unix is all about "do one thing, well".

Actually, it's the NetBSD gzip, which has support for bzip2 and xz
decompression despite separate tools exist...

(But I see that this approach solves the problem, needing to add new
switches to tar, for a new compression tool every decade or so.)

> Thus, compression and decompression do not belong in tar; they belong
> in separate (de)compression tools.  That other (supposed) Unix variants
> have made a mistake does not mean NetBSD should make the same mistake.

I'm not suggesting to add any (de)compression code to tar. I'm not even
suggesting to add a switch to call a new (de)compression tool (maybe LZO
or LZ4). I'm simply suggesting to connect a short option to an
_already_existing_ long option (--xz). Because in my opinion

  tar xf file.tar.xz --xz

is not much shorter and easier to type than

  xzcat file.tar.xz | tar xf -

while

  tar xJf file.tar.xz

really is.

So, yes we could remove all those switches related to compression
(breaking compatibility) to have a really clean approach, or make the
_existing_ ones more handy and therefore really useful. And as I wrote,
it adds two bytes to the binary, and the C code gets even shorter.