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.

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.

--apb (Alan Barrett)