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?

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

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