[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: option abbreviation exceptions

From: Jim Meyering
Subject: Re: option abbreviation exceptions
Date: Sat, 10 Jan 2009 22:32:31 +0100

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]