Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> According to Jim Meyering on 12/29/2008 10:02 AM:
>>> $ /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.
>
> What do you think of this patch?  It changes programs that take exactly
> one of the two mandated options to only recognize exactly "--help" or
> "--version" but not abbreviations.  After the patch, I get:

"[" 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 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.

> $ src/basename --oops
> src/basename: invalid option -- -
> Try `src/basename --help' for more information.
> $ src/basename --help me
> src/basename: invalid option -- -
> Try `src/basename --help' for more information.
> $ src/basename --hel
> src/basename: invalid option -- -
> Try `src/basename --help' for more information.
> $ src/basename --help | head -n2
> Usage: src/basename NAME [SUFFIX]
>   or:  src/basename OPTION
> $ src/echo --he
> --he
>
> In other words, most programs will treat --h identically to --oops,
> diagnosing it as an invalid option (since the application only takes one
> of two specific options), and exceptional programs, like echo or [, which
> react differently to invalid options, will react the same way to an
> abbreviation as to any other invalid option.

BTW, "most" coreutils programs wouldn't be affected.
Only those that accept no other long options are affected.
In coreutils, it looks like ~28 programs would be affected:

    $ grep -l long-options.h *.c
    basename.c
    chroot.c
    cksum.c
    dd.c
    dirname.c
    echo.c
    expr.c
    getlimits.c
    hostid.c
    hostname.c
    link.c
    logname.c
    nice.c
    nohup.c
    printenv.c
    printf.c
    pwd.c
    setuidgid.c
    sleep.c
    sync.c
    test.c
    timeout.c
    tsort.c
    unlink.c
    uptime.c
    users.c
    whoami.c
    yes.c