[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: |
Mon, 29 Dec 2008 18:02:39 +0100 |
Eric Blake <address@hidden> wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
>
>> Some of these programs recognize the @option{--help} and @option{--version}
>> -options only when one of them is the sole command line argument.
>> +options only when one of them is the sole command line argument. For
>> +these programs, abbreviations of the long options are not recognized.
>
> In subsequent testing, I realized this is not entirely true. Should I work on
> a followup patch that makes this sentence true?
Simplest might be to change "not recognized" to "not always recognized".
> For example,
>
> $ /bin/echo --help --version | head -n1
> --help --version
> $ /bin/echo --help | head -n1
> Usage: /bin/echo [OPTION]... [STRING]...
> $ /bin/echo --he | head -n1
> Usage: /bin/echo [OPTION]... [STRING]...
> $ /bin/echo -n -e hi\\n | head -n1
> hi
>
> Certainly some inconsistent behavior. echo takes multiple arguments, but only
> when they are the short options -[neE] (I guess it's okay that they don't have
> long-option variants?).
Yes, I think so. coreutils' echo is so old and rarely used
that it doesn't matter. People should be using printf instead.
> But when --help or --version is present, echo acts
> like it takes exactly one argument. The usage text doesn't really portray
> that. The other thing that is awkward is that we are recognizing
> abbreviations; it seems like it would make more sense for "echo --he" to
> output "--he" rather than the help text. POSIX isn't much help here, either,
> as it only specifies that portable apps can't use -n (but says nothing about -
> e), and we are already violating the (lame) POSIX requirement that -e be on by
> default, thus giving no guidance on whether we are better off requiring the
> user to write "/bin/echo -ne" instead of "/bin/echo -n -e" when they want both
> options.
>
> Another case in point:
>
> $ /bin/[ --help me | head -n1
> /bin/[: missing `]'
> $ /bin/[ --help | head -n1
> Usage: test EXPRESSION
> $ /bin/[ --hel | head -n1
> Usage: test EXPRESSION
>
> Should the last example also complain about missing `]', rather than printing
> help text?
test and [ have always had a conflicted relationship
with --help/--version.
Making [ accept no abbreviations does seem like it'd be an improvement.
- Suggestion for rmdir, Adam Jimerson, 2008/12/27
- Re: Suggestion for rmdir, Eric Blake, 2008/12/27
- Re: Suggestion for rmdir, Adam Jimerson, 2008/12/28
- Re: Suggestion for rmdir, Eric Blake, 2008/12/27
- Re: Suggestion for rmdir, Jim Meyering, 2008/12/27
- option abbreviation exceptions (was: Suggestion for rmdir), Eric Blake, 2008/12/29
- Re: option abbreviation exceptions, Eric Blake, 2008/12/29
- Re: option abbreviation exceptions, Jim Meyering, 2008/12/29
- Re: option abbreviation exceptions, Pádraig Brady, 2008/12/30
- Re: option abbreviation exceptions, Eric Blake, 2008/12/30
- Re: option abbreviation exceptions,
Jim Meyering <=