2009/228 ls enhancements

[James Carlson]

Don Cragun writes:
> 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.

Yes; I agree with your description.  That'd better work as documented.
If it doesn't, then it's a bug, and we'll have to fix it.

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

Correct.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677