Subject: Re: RFC: getopt_long(3) change
To: None <tech-userlevel@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-userlevel
Date: 06/23/2007 15:25:38
In article <20070623080627.GA18016@arresum.veego.de>,
Bernd Ernesti <tech-userlevel@netbsd.org> 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?
>
>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.
>
As with most things in life there are pros and cons making this change.
In this case, I feel that we should make the proposed change (accept
ambiguous arguments) because this is what the gnu getopt_long() does
and most 3rd party programs expect the gnu behavior. Let's face it,
we wrote getopt_long() in the first place not only because we needed
the additional functionality, but also because we wanted 3rd party
programs to link without needing extra files.
christos