Elad Efrat | 23 Jun 17:23 2007
Bernd Ernesti | 23 Jun 18:04 2007
Picon

Re: RFC: getopt_long(3) change

[tech-security added to the list to get some attention from there]

On Sat, Jun 23, 2007 at 03:25:38PM +0000, Christos Zoulas wrote:
> In article <20070623080627.GA18016 <at> arresum.veego.de>,
> Bernd Ernesti  <tech-userlevel <at> 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'
(Continue reading)

David Laight | 23 Jun 18:31 2007
Elad Efrat | 23 Jun 18:39 2007
Elad Efrat | 23 Jun 18:43 2007
Elad Efrat | 23 Jun 19:11 2007

Gmane