Subject: Re: RFC: getopt_long(3) change
To: None <tech-userlevel@netbsd.org>
From: Alan Barrett <apb@cequrux.com>
List: tech-userlevel
Date: 06/23/2007 09:05:11
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.

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

Please update the man page, which currently doesn't say anything about
abbreviations.

--apb (Alan Barrett)