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

[Don Cragun]

>Date: Tue, 03 Jul 2007 17:53:17 +0200
>From: Joerg.Schilling at fokus.fraunhofer.de (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.

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.

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

Fortunately, the vast majority of Solaris utilities have much less than
25 option letters in use.

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

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

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

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

You're grossly overstating what the POSIX authors would like here.  The
POSIX standard reserves the -W option for vendor specific extensions
and promises that it will never standardize an option using "W" as the
option character.  The POSIX standard never suggests that all vendor
extensions should be implemented as -W "something".

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

 - Don

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