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

[Joerg Schilling]

Don Cragun <don.cragun at sun.com> 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.
>
> This is true for all options, not just those using "special" option
> characters.  As you have already pointed out, there are lots of options
> and too few available option characters to make single character
> options unique.  So, we do our best to use consistent option characters
> for "similar", "related" Solaris utilities.

This is a good reason to introduce long options.


> >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:
> >
>
> You don't need to explain the POSIX standard for me.

You are not the only person to receive this mail. I did at least see one person
from Sun during the past week who may benefit from the explanation ;-)

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

...

> This is totall irrelevant here.  The "-/ verbosity_flag" and "-%
> timestamp" options fully support the Utility Syntax Guidelines except
> (as pointed out in the case submission) guideline #3 (which says that
> option characters "should" be alphanumeric character from the portable

Currect, so they deviate in one point from the Utility Syntax Guidelines.
They would also deviate in one point of long options would be used instead.

Another problem is that -% would need quoting on my shell. This problem
could be avoided by not using -%.


> character set.  The -/ and -% option arguments are shown in the
> synopsis as separate arguments as suggested by USG #6.  But, "-/ c" and
> "-/c", "-/ v" and "-/v", "-% crtime" and "-%crtime", and "-% all" and
> "-%all" are all accepted as suggested by the POSIX/SUS Utility Argument
> Syntax point 2.  As suggested by USG #7, -/ and -% option arguments are
> not optional.

You do not need to explain the POSIX standard for me. 



> >-	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.
>
> The PSARC CLIP case (1999/645) guideline #18 says that when long
> options are used, each long option should have a single character
> option equivalent and each single character option should have a long
> option equivalent.  So, converting to long options does not get rid of
> the problem.

It makes no sense to point to rules that are not written the right way.

One important reason for introducing long options is to extend the option
name space and to allow to use similar or equal option names for more than
one utility if these utilities implement similar or equal tasks behind this 
option.

I don't know why someone tries to mandate that every long option should have
a short option equivalent. It looks to me as if somebody did use the 
disadvantages of the Sun getopt() implementation as prototype for some 
guidelines.

As I pointed out before, POSIX does not require that a usility uses getopt()
for option parsing and there is a better option parser that is better than 
getopt() which is available under the CDDL. My getargs() implementation is fully
POSIX Utility Syntax Guidelines compliant and allows to implement long options 
without the need to a short option equivalent.

The conversion from getopt() to getargs() is simple in case that the utility
follows USG #11, which is mainly the case for the documented behavior of ls(1).

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