2009/228 ls enhancements

[Glenn Fowler]

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

side note -- the ast optget() also disambiguates optional option values
for long options by requiring the name=value form
it also allows long options with no corresponding short flags by
using negative indices that will not conflict with short flag character values

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

-- Glenn Fowler -- at&t Research, Florham Park NJ --

On Fri, 1 May 2009 00:47:18 -0500 Jason King wrote:
> On Fri, May 1, 2009 at 12:31 AM, Don Cragun <dcragun at sonic.net> wrote:
> > 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.

> Then this sounds like a bug in getopt_long -- a leading '+' it does in
> fact make all long option-arguments mandatory.  I thought that's what
> it should do, but since it doesn't it was making me doubt my
> comprehension abilities :)

> Actually reading the code it would appear that in this section:
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/getopt_long.c#495
> the last statement (line 498) shouldn't be there.  Would you agree
> that is a bug (the removal FLAG_OPTIONAL_ARGS when POSIX mode is set)
> and not in fact an architectural issue?

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

> That would be what I would expect as well.

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

> I agree.

> > Hope this helps,
> > Don
> >

> I believe so, thank you very much!
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org