Busybox and standards/direction, old tar options

[Glenn L. McGrath]

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.

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.

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.

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

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.

With old options the order of the option indicates the order of the
arguments e.g.
These both work
$ tar xfC . foo.tar
$ tar xCf foo.tar .
These both fail
$ tar xfC foo.tar .
$ tar xCf . foo.tar

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

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

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.

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.


> 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.



Glenn