Busybox and standards/direction, old tar options

[Rob Landley]

On Monday 12 December 2005 18:02, Glenn L. McGrath wrote:
> On Sun, 11 Dec 2005 13:40:51 -0600
>
> Rob Landley <rob at landley.net> wrote:
> > On Sunday 11 December 2005 07:10, Glenn McGrath wrote:
> > > When trying to _define_ a standard there will always be people who
> > > think this should be in the standard or that shouldnt be in it. So
> > > multiple standards can be defined at the same time targeting different
> > > demographics.
> >
> > Standards should document, not legislate.  "This is the existing best
> > practice" is a good thing.  "We think you should do it this way" is
> > seldom a good thing to come out of a committee.
>
> I hate the concept of pax, its a utilitiy created by a standards body
> becasue on paper they wanted one standard archiving format and both tar
> and cpio were used in practice. The standards bodies solution was to
> create utuility that supports both formats and define it as the
> standard.

Somebody suggested we add pax support while you were away, and I believe Erik 
handed them their head. :)

> I think its good to support people who understand but disagree with a
> standard, but i have no sympathy for people for follow old standards
> becasue they are lazy.

I can see deprecating stuff, and yanking it (ipchains and devfs come to mind).

If you'd posted a patch to yank the numeric options entirely, I probably would 
have been less uncomfortable with it.  (I'd have objected to it going into 
1.1 this late in the cycle, but might have queued it first thing for 1.2.)

I.E. I don't see a reason to yank it, but I'm also not strongly motivated to 
defend it, either.  I could be talked into it.  It's the propogation of 
config options that really gets my attention.

If we can justify yanking something, yank it.  If we can't, leave it.  Forking 
our user interface is disquieting.  (And this month ain't the time for making 
these decisions. :)

> Laziness is how i see the situation with numeric argument. -<num>
> arguments were removed because its inconsistent with standard option
> parsing, imagine if people started wanting to doing -<string> without
> typing the opion name. It could get very confusing, and hard to parse.
>
> Which reminds me, i disagree in principle with supporting old tar
> options (short options with out the leading '-') GNU considers them
> obsolete and we arent doing it properly anyway.

This hits closer to home with me, because I've gone "tar xvjf" for long enough 
that it's hardwired into my fingers.  This is a user interface issue, there 
are people out there who use command lines who want "ps ax" and "tar xvjf" 
and right now we don't handle these properly.

Saying "we refuse to support the user interface you're used to, you must use 
_this_ user interface to use our version of your tool" just means that we 
drive people away.

And yes, I would personally refuse to use busybox tar over this.  I would 
maintain my own patch to put it back, come up with some kind of wrapper shell 
script.  On purely user interface grounds.

> e.g.
>
> $ tar cCf . foo.tar AUTHORS
> $ ./busybox tar cCf . foo.tar AUTHORS
> tar: Couldnt chdir to f: No such file or directory
>
> $ tar xfC . foo.tar
> $ ./busybox tar xCf . foo.tar
> tar: Couldnt chdir to f: No such file or directory

Notice: this is a uClibc bug.  As far as I can tell, it works with glibc, but 
doesn't with uClibc.

> There is section in the tar info pages on old options, its more complex
> than just putting a '-' infront of things, it can also require re-ordering
>  parameters.

And I don't care about the standard, I care about what people use.  There are 
8 gazillion examples of "tar xvjf" out in the wild.

> With old options the order of the option indicates the order of the
> arguments e.g.

You're saying that with dashes it doesn't?  (Checks...)  Huh, apparently not.  
Never noticed before.

> These both work
> $ tar xfC . foo.tar
> $ tar xCf foo.tar .
> These both fail
> $ tar xfC foo.tar .
> $ tar xCf . foo.tar

Or vice versa, anyway.

> I thinks old tar options are something left buried, better to encourge
> people to update the behaviour to use short options.

I don't think encouraging people to update their behavior for the priviledge 
of using our tool is an effective strategy.  Really, I don't.

Making the old interface a CONFIG option, sure.  I can get behind that 100% 
(although what I'd get behind is one global switch to enable old interfaces 
in all the places we care to mark, and having a CONFIG_NITPICK if we want to 
break these into individual switches).

> e.g. all of these work and its easy to see which paramater belongs to
> which option.
> $ tar -xC . -f foo.tar
> $ tar -xf foo.tar -C .
> $ tar -x -f foo.tar -C .
> $ tar -x -C . -f foo.tar

It's actually kind of strange to me that you can group -xC but not -Cf.  But 
if that's what the gnu version does and what the spec says, then obviously 
that's right...

> And if people do think that the old tar option behaviour is a good
> thing then i would expect them to want to apply the same concept to all
> applets, not just tar.

You mean like "ps ax" which I keep doing under busybox and which annoys me 
every time?

Different commands have different syntax.  They always have.  X apps have a 
different syntax from gnu apps which have a different syntax from our legacy 
v7/BSD apps.  Railing against widespread common usage isn't really part of 
our mandate, is it?  We're trying to do minimal implementations of what 
people actually use.

> I dont like it in ar etiher, but at least in ar its not considered
> obsolete by any upstream (possibly because ar is somewhat neglected),
> and there has never been an ar standard.

There's never been an init standard (I've looked, if you can find one please 
tell me).  Strangely, this lack of documentation is somewhat inconvenient but 
doesn't bother me on a deep existential level.

And yes, I consider a standard to be documentation.  Where documentation 
doesn't match common usage, then the documentation is either wrong or useless 
(and which one is a matter of opinion).

> > One approach that has a certain attraction to me is to put every single
> > applet together in one big menu, alphabetically, and then have another
> > menu with selection items for categories, which we could set to Y, N, or
> > M.  (Which to _us_ would mean Yes, No, Maybe.)  Y means select everything
> > in that category, N means hide everything in that category, and M means
> > make everything in that category show up for individual selection in the
> > big list...
> >
> > We have several different options...
>
> Hmm, so we have a low level configuration menu where experienced users
> can tweak to their hearts content, and a high level menu that just
> beascially uses presets on the lower level configuration options...
>
> Sounds reasonable to me.

Something like that.  I'd put master switches like (CONFIG_NITPICK) in the 
first menu (possibly the general options and build menu should be merged 
somehow), and then have the options for an applet attached to the applet, but 
not actually visible unless you select the appropriate granularity.  (We 
should probably have some simple rule, like any invisible feature switch can 
be considered selected.  Something easy to think about.)

We're already trying to consistently mark all features with CONFIG_FEATURE, 
which lets "make allbareconfig" work.  (Which is a _marvelous_ testing thing, 
and something we just broke again in the last 24 hours...)

> Glenn

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.