Subject: Re: RFC: getopt_long(3) change
To: None <tech-userlevel@NetBSD.org>
From: Brian Ginsbach <ginsbach@NetBSD.org>
Date: 06/26/2007 21:19:51
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
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
> 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.
This does not seem reasonable in light of support for abbreviations
and how other implementations of getopt_long(3) work.