Subject: Re: RFC: getopt_long(3) change
To: None <email@example.com>
From: Brian Ginsbach <ginsbach@NetBSD.org>
Date: 06/26/2007 21:19:05
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
> > Please update the man page, which currently doesn't say anything about
> > abbreviations.
> > --apb (Alan Barrett)
> David Laight: firstname.lastname@example.org