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
