On Sat, Jun 23, 2007 at 08:45:07AM +0100, David Laight wrote:
> 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.

Note that this change does not add support for partial matches!
It has been there.  I think this "feature" came from the GNU folks.
Note that FreeBSD made a similar ambiguous match fix over 3 years ago.

> 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.

Yup, but again that horse has already left the barn.  This change
just rationalizes that behavior a bit better.  IMHO the current
version violates POLA.

> 
> > > 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!

Hey, I can't claim that the program where I first encountered the problem
had the best design.  But it expected that getopt_long(3) was really
GNU getopt_long(3).

>  
> > Please update the man page, which currently doesn't say anything about
> > abbreviations.
> > 
> > --apb (Alan Barrett)
> 
> 
> 	David
> 
> -- 
> David Laight: david@l8s.co.uk