option abbreviation exceptions (was: Suggestion for rmdir)

[Eric Blake]

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?

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?).  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?

-- 
Eric Blake