2009/228 ls enhancements

[James Carlson]

Glenn Fowler writes:
> there are no posix standards for long options
> so it should not be a problem for a long option
> with no corresponding short flag to have an optional option value,
> of course assuming that the name=value form would be required to 
> disambuguate when the option value is present

POSIX isn't really the issue here for long options.  As you rightly
note, POSIX defines only short options (and even at that, leaves some
things to the imagination).

The standards we're discussing here are actually set by ARC case
history.  PSARC 1999/645 (CLIP), 1991/031 (getopts), and 2003/035
(getopt_long and getopt_clip) are the relevant cases.

> a bonus is that ksh93 uses optget() to implement getopts
> so shell scripts are not second class citizens w.r.t. long options
> and since the options desc ription is one 0-terminated string
> instead of a C-data-struct the description can be moved
> freely between script<=>C-source implementations

Since this is going in ON, I think the implementor is free to choose
among the getopt_* family and the ksh93 optget() functions as he sees
fit.  There's no real architectural issue there, as far as I can tell,
as long as the functionality described is implemented.

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