On Sat, Jun 23, 2007 at 09:05:11AM +0200, Alan Barrett wrote:
> On Fri, 22 Jun 2007, Brian Ginsbach wrote:
> > The long options are set so that both "color" and "colour" would
> > be supported and both return the same value when parsed.  There
> > are no other long options that start with "col".
> > 
> > A command is passed the option --col.  The current version of NetBSD
> > getopt_long(3) treats this as an ambiguous argument.  This was the
> > behavior of GNU getopt_long(3) for GNU C library 2.1.3.  Later
> > versions of the GNU C library doesn't treat this as ambiguous.
> 
> Thank you.  So the fix is something like "if it looks like an ambiguous
> abbreviation of two or more long options, but all the possible
> interpretations would return the same value, then just return that value
> without complaining that it's ambiguous."  This seems sensible.

Actually it is a stupid idea!
Or rather allowing partial matches is what is stupid.
It is all very well when the commands are typed at the keryboard,
but the shortened forms will end up in shell scripts.
Then, another option will get added that has the same initial part
and the scripts suddenly starts failing after the program gets updated.

> > The change also fixes the handling of single character options that
> > are both a long option and a short option and there are options
> > that start with the same character.  Note the long option parses
> > to a different value than the short option.
> 
> And here, I assume the fix is "if it could be interpreted either as an
> exact match for one long option, or as an abbreviation for one or more
> other long options, then treat it as the exact match."  This too seems
> sensible.

That one is fine, but does seem to mean a lack of imagination on behalf
of the program designed!
 
> Please update the man page, which currently doesn't say anything about
> abbreviations.
> 
> --apb (Alan Barrett)


	David

-- 
David Laight: david@l8s.co.uk