On Sat, Jun 23, 2007 at 10:06:27AM +0200, Bernd Ernesti wrote:
> 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.
> > 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.
> 
> What happens when I accidentally mistype a char and so this 'feature'
> use a different function, which does the opposite of what I wanted, because
> the different char now case a match for the other function instead of
> failing?

Note, the partial match "feature" is already in our version of
getopt_long(3).  My change does not add it.

If the example was changed slightly, there was only one long option
"color", and the command was called with --col it would be accepted
as as an abbreviation for --color.

I think even without the proposed change you could still get the
behavior you describe.

> 
> Or am I missing something here what you plan to change?
> 

I think you are missing something.  Again, the change only rationalizes
and end case.  If the option is truly ambiguous it will be flagged
as such.

> In short: I don't like this intelligent way to decide which option should be used,
> it should always fail if the option is ambiguous.
> 
> Bernd

This does not seem reasonable in light of support for abbreviations
and how other implementations of getopt_long(3) work.