On Sun, Jun 24, 2007 at 11:07:06AM +0200, Alan Barrett wrote:
> On Sat, 23 Jun 2007, Christos Zoulas wrote:
> > 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.
> 
> It's not really about what the programs expect; it's more about what the
> callers of the programs expect.  If a program has a "--color" option and
> a "--colour" option, and use getopt_long(3) to parse its command line
> options, then whether or not the program can be successfully invoked
> with options like "--colou", "--colo", "--col", etc., are more or less
> invisible to the program itself.  It doesn't affect whether or not
> the program links, and it doesn't affect the program's behaviour when
> invoked without abbreviations of long options.  It does affect the
> program's behavious when invoked with abbreviations of long options, but
> I'd say that this is an issue about the caller's expectations, not the
> program's expectations.
> 
> I think that the debate that Bernd Ernesti is wanting to open
> is: "Should getopt_long(3) ever allow abbreviations of long options?"
> My opinion is that I'd prefer not to allow abbreviations, but I
> think it's too late for that, so I think we are stuck with allowing
> abbreviations.

Agreed, it is too late as the current code already allows abbreviations.
It is also what will be expected of getopt_long(3) as this is what
the de facto standard GNU version does.

> 
> What to do in the "--colour"/"--color" case, where two long options have
> different spellings but the same meaning, is a separate question.  I
> think the answer should be: If abbreviations are not allowed at all,
> then "--col" should not be allowed, but if abbreviations are allowed,
> then "--col" should work.  The status quo, in which abbreviations are
> usually allowed but "--col" doesn't work, seems wrong.
> 

I have no disagreement with either of these.  But again, I don't
think we can say that our version of getopt_long(3) won't support
abbreviations.

> --apb (Alan Barrett)

So does this change really require a ruling from core?