Eric Blake <[email protected]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
