2009/228 ls enhancements

[Don Cragun]

Jason King wrote:
> On Thu, Apr 30, 2009 at 4:16 PM, James Carlson <james.d.carlson at sun.com> wrote:
>> Jason King writes:
>>> After lots of reading, rereading, parsing, and reparsing, I believe
>>> using getopt_long(3c) to process the arguments, with '+' being the
>>> first character of the option string, gives the desired behavior
>>> (without breaking any standards).
>> Yep; I think you're on the right path.
> 
> Upon further investigation, this will not allow optional long
> arguments (I thought it did), so now I'm at a loss, and my head hurts
> from trying to decipher what is, what isn't standard conforming.
> 
> So, I will simply ask, is there any facility in Opensolaris that supports:
> 
> 1. Long and short options, where there might be long options that
> don't have corresponding short versions
> 2. Long arguments that can have optional parameters of the form
> --option=FOO, or --option but not '--option foo')
> 3. Long arguments that can have mandatory parameters of the form
> --option=FOO or --option foo
> 4. Doesn't break POSIX or SUS standards.
> 
> If so, what is the correct invocation to achieve this, because I seem
> unable to figure it out.
> 
> getopt_long(argc, argv, "+......", longopts, &indexptr) apparently
> requires all parameters to long options as mandatory.  I.e. 'ls
> --color' does not work.  My understanding is getopt_long(argc, argv,
> "....", longopts, &indexptr) where the first character is not '+'
> allows argument reordering and is therefore not posix compliant (but
> does allow --option[=FOO].  It looks like "-....." for the short
> option string might, but at this point I've given up trying to
> understand the getopt_long manpage as everything I think i've
> understood it, I find yet another case to prove me wrong, so please
> anyone who actually understands this, please comment.

Hi Jason,
I helped spec out, write, and debug getopt_clip(); but as you have noted
that won't work unless all long options have short option equivalents
(and getopt_clip() doesn't like optional option-arguments).

The leading "+" in the string pointed to by the shortopts parameter only
forces the POSIX/SUS/CLIP requirement that command line parsing is not
allowed to reorder arguments on the command line; it doesn't affect
optional option-argument processing.

My reading of the getopt_long() description is that if the element of
the getopt_long() struct option array pointed to by the longopts 
parameter has name set to "color" and has has_arg set to
optional_argument (as defined in <getopt.h>), getopt_long() should 
recognize either of the following as a valid invocation with --color:
	ls --color [other options]... [operands]...
which is used when the optional option-argument is not present
or 	ls --color=value [other options]... [operands]...
when the optional option-argument is present.  The getopt_long()
function will not recognize "value" in:
	ls --color value
as an optional option-argument because it can't be distinguished from
	ls --color operand
where operand is a command line operand instead of the optional
option-argument.

I believe the PSARC members who voted to approve this case Wednesday
did so with the understanding that optional option-arguments could be
parsed unambiguously.  Therefore, the form:
	ls --color optional_option_argument
can't be accepted.

Hope this helps,
Don