ls(1) new command line options '-/' and '-%': CIFS system attributes support [PSARC/2007/394 FastTrack timeout 07/11/2007]

[Joerg Schilling]

Darren J Moffat <Darren.Moffat at Sun.COM> wrote:

> Joerg Schilling wrote:
> > The option -/ is already used by star:
> > 
> > -/              don't strip leading '/'s from file names
> > 
> > I believe that special characters like '/' should be use for similar tasks
> > in order to make it easier to memorize options.
>
> Joerg:
>
> there are already HUGE clashes of option letters between ls(1) and 
> tar(1) and what they mean

Darren, these clashes are historical and cannot be avoided. I believe that
today, when most programs implement a lot of options, we need to take much more
care about usability of the resulting system. I see more than 1000 programs in
/usr/bin and if every program implements only 25 short options, then I would 
need to remember 25,000 different options - many of them most likely 
contradicting between programs. In such an enviroment, short options become
unusable while long options make it easier to remember the meaning and even
could allow to use similar options for similar behavior.

Let me try to explain the POSIX standard for this case. As POSIX does not 
define a new standard from scratch but just documents existing practice, there
are many irregularities in the CLI definitions for the various utilities from 
the POSIX standard. There are e.g. programs that define something like '-Fc' 
and others that define '-F c'. The first does not like to see a space between 
the option and the parameter, the second needs a space. The related standard 
that writes down the rules for utilities is here:

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html

Let me explain the wording to avoid confusion:

-	"must" or "shall" defines a "law", you are not allowed to ignore
	such a definition.

-	"should" defines a "rule", something that is desired but not 100%
	mandatory.

The word "shall" is used mainly to write down that some applications
are defined by '-Fc' option definitions while the POSIX standard likes 
to see '-F c'. A utility that has '-Fc' in the documentation _needs_ to 
implement '-Fc' and '-F c' in order to be POSIX compliant.

All other CLI basic definitions are rather "rules" and thus may be ignored if 
this cannot be avoided.

In order to be able to judge on a new option, it may make sense to check how 
many of the POSIX rules would be ignored if it would be implemented.

Let me first start with something unrelated but probably of interest.
The POSIX CLI guidlines say that an option should be a single letter and
should be behind the "-" delimiter.

-	Implementing an option '-foo' would ignore one of the rules from
	the POSIX CLI guidlines.

-	Implementing an option '--foo' would ignore two of the rules from
	the POSIX CLI guidlines.

The options in this proposal are clearly vendor unique extensions, so POSIX
would like them to be hidden behind '-W something', where "someting" is a 
single argument to the application. 

-	Implementing '-/ v' ignores one of the rules from the POSIX CLI 
	guidlines (not using -W for vendoer unique extensions). 

-	Implementing something like '-attr' would also only ignore one of
	the rules from the POSIX CLI guidlines (option names should be single
	letters).

Similar conclusions apply to the -% proposal. For this reason, I would
like to know why not a long option was chosen instead.

I don't like to see -/ nor -% in ls(1) and am not willing to aprove this case.

It seems that you Darren would also prefer a different solution.


Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       schilling at fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily