Re: [hackers] [PATCH] tar: if first argument doesn't have a leading dash, prepend one

From: Ethan Sommer <e5ten.arch_AT_gmail.com>
Date: Mon, 18 May 2020 15:43:02 -0400

On Mon, May 18, 2020 at 3:36 PM Laslo Hunhold <dev_AT_frign.de> wrote:
>
> On Mon, 18 May 2020 12:18:33 -0700
> Michael Forney <mforney_AT_mforney.org> wrote:
>
> Dear Michael,
>
> > Whether you like it or not, it's the most common usage of tar by far,
> > and as far as I know, the only one that was ever standardized. You are
> > not forced to use this syntax, the usage following the Utility Syntax
> > Guidelines still works after this patch.
>
> that's understandable. I was more talking more for the sake of
> consistency and of course agree that you're right.
>
> > On what basis are scripts written to the SUSv2 specification broken?
>
> On the basis of how flags and operators work for common terminal tools.
>
> > Because we said so? Ethan looked at a bunch of tar implementations,
> > and some did not support the hyphenated options. Therefore, the most
> > portable way to call tar is with the old-style options.
>
> If we looked at other implementations for sbase all the time we'd end
> up with the GNU coreutils at the end. This approach moves us, inch by
> inch, closer to some inconsistent mess. However, I agree that the
> "standards body" is nonexistant for tar.
This isn't about matching some GNU-specific behaviour though, this is
about sbase tar being able to be used by scripts trying to support all
tar implementations. There are numerous tars that support both styles,
and also many that only support the dashless argument, but sbase tar is
the only tar implementation I can find that only supports the argument
with a dash. Without supporting dashless arguments in sbase tar, it
makes it impossible to support both sbase tar, and many other tars, in
the same script, which decreases the script's portability unnecessarily.
It doesn't seem reasonable to me to force script writers to either drop
support for many other tar implementations that would otherwise work, or
to continue to not work with sbase tar.
>
> > Personally, I think tar is a hopeless interface and we should
> > implement pax in sbase. I started on an implementation a while ago,
> > but it is unfinished. After this, we can remove this tar
> > implementation, which has some known bugs and deficiencies, and
> > possibly replace it with a tar compatibility interface to pax. This
> > tar compatibility interface should probably support the hyphen-less
> > option key, since its whole purpose is legacy compatibility.
>
> I completely agree there. However, pax is so little-known and never
> picked up pace really. It's not an argument against implementing it,
> but does anybody know the reason why it is so?
>
> With best regards
>
> Laslo
>
Received on Mon May 18 2020 - 21:43:02 CEST