Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> According to Jim Meyering on 1/10/2009 10:48 AM:
>> "[" feels like it should be the exception.
>> I see treating --v like --version as a feature.  a typing saver.
>> But with "[", it's good to minimize the number of strings that
>> make it act differently.
>>
>> Besides, why make everyone type it all out if there's no need?
>
> Then maybe the better approach would be adding a parameter to
> parse_long_options (or rather, creating a new function with an extra
> parameter, and making parse_long_options default to calling it with the
> parameter at 0, but make echo and [ call it with the parameter set to 1),
> where having the parameter set controls whether --h is ignored (the
> exception, for echo) or treated as an abbreviation (the rule, for things
> like basename).
>
> Or, for echo and [, we could skip parse_long_options altogether, and
> hardcode this instead:
>
> argc == 2 && (STREQ (argv[1], "--help") || STREQ (argv[1], "--version"))

One of those approaches would be good.
Whichever you prefer.

>> Then you don't have to "know" that a program accepts only
>> --help and --version, and hence accepts no abbreviations,
>> versus those that accept at least one more long option, which
>> do provide the feature.
>>
>> Also, it'd mean adding a third option would have
>> the side effect of enabling --h and --v recognition.
>
> That's kind of what happened with expr vs. factor.  Since
> parse_long_options only recognizes exactly one argument as a long option,
> adding another option already has a side effect:
>
> $ src/factor --help | head -n1
> Usage: src/factor [NUMBER]...
> $ src/factor --help --version | head -n1
> Usage: src/factor [NUMBER]...
> $ src/expr --help | head -n1
> Usage: src/expr EXPRESSION
> $ src/expr --help --version | head -n1
> src/expr: syntax error
>
> expr currently uses parse_long_options, while factor does not; therefore
> factor is able to handle --help --version while expr is not.

I see it the other way ;-)
factor mistakenly accepts the combination of --help --version.
Actually, I see a small problem: factor doesn't document in --help
output the relatively new --verbose option.

And expr is similar to test and "[" in accepting
arbitrary strings, so it minimizes the impact of accepting
--help and --version.

> Maybe parse_long_options should be taught to recognize multiple options
> that all match an abbreviation of --help/--version, rather than expecting
> exactly one option?

I think of --help and --version are exclusive,
since by definition each prints something and exits.
So it doesn't make sense to use them together.