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 :)
I know that some of the GNU developers believed (and some may still
believe) that POSIXLY_CORRECT meant that no options could be accepted if
they weren't in the standard, that the "Utility Syntax Guidelines" were
to be treated as "requirements" instead of as "guidelines", and that
POSIXLY_CORRECT was a method allowed by the standard to invoke standard
behavior. All of these beliefs were incorrect. (However, the latest
version of the standard allows POSIXLY_CORRECT to have this affect if
the command output by invoking the command:
getconf V7_ENV
sets POSIXLY_CORRECT.)
The POSIX and SUS standards still have a few standard utilities that
take optional option-arguments. The description of those utilities
always explicitly lists every case where a standard utility violates the
Utility Syntax Guidelines. When writing new applications, it is up to
the programmer to follow the guidelines (by not creating optional
option-arguments); it was never the intent of the standards committees
that getopts() or other command line processing functions should make it
exceptionally hard to process optional option-arguments for those
utilities that need to support them for backwards compatibility or other
reasons.
>
> 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?
Yes, I agree that this is a bug in getopt_long().
>
>> 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!
You're welcome.
- Don
