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!
