Don Cragun writes: > 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.
Yes; I agree with your description. That'd better work as documented. If it doesn't, then it's a bug, and we'll have to fix it. > 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. Correct. -- 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
