Eric Blake <ebb9 <at> byu.net> writes: > 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.
Would this usage text be acceptable at better describing the situation? Usage: /bin/echo [SHORT-OPTION]... [STRING]... or: /bin/echo LONG-OPTION Using 'git grep " OPTION"', I've come up with this additional list of programs where I think we are inconsistent: src/basename.c: or: %s OPTION\n\ 'basename --help --version' is rejected, but not 'basename --hel'. Should we treat "basename --oops" as equivalent to "basename -- --oops", rather than causing an error? src/chroot.c: or: %s OPTION\n\ $ chroot -- --hel chroot: cannot change root directory to --: No such file or directory Oops, there's a bug; the message should have mentioned --hel, not --. Meanwhile, should we treat "chroot --oops" like "chroot -- --oops"? src/dd.c: or: %s OPTION\n\ 'dd --help --version' is rejected, but not 'dd --hel'. src/dirname.c: or: %s OPTION\n\ Similar to basename. src/expr.c: or: %s OPTION\n\ 'expr --help --version' is rejected (but with a different error than with other coreutils), while 'expr --hel' works. src/factor.c: or: %s OPTION\n\ Unlike expr, 'factor --help --version' works. src/hostid.c: or: %s OPTION\n\ 'hostid --help --version' is rejected. But perhaps this usage should be written in one line, instead of two: Usage: hostid [OPTION] src/hostname.c: or: %s OPTION\n\ Like dirname, should 'hostname --oops' be treated as 'hostname -- --oops'? src/link.c: or: %s OPTION\n"), program_name, program_name); 'link --help --version' is rejected, but 'link --hel' works. src/nohup.c: or: %s OPTION\n\ 'nohup --help --version' is rejected, but 'nohup --hel' works. Also, should 'nohup --oops' behave like 'nohup -- --oops'? src/printenv.c: or: %s OPTION\n\ 'printenv --help --version' is rejected, but 'printenv --hel' works. src/printf.c: or: %s OPTION\n\ src/printf.c:Print ARGUMENT(s) according to FORMAT, or execute according to OPTION:\n\ $ /bin/printf --help --version --help/bin/printf: warning: ignoring excess arguments, starting with `--version' Ouch. This both printed to stdout, and to stderr. It would have been nicer to keep the error but do nothing on stdout, or to print both strings with no error. But this is one case where we have the extension already in place that '/bin/printf --oops' behaves like the intended '/bin/printf -- --oops', rather than issuing an error. I do like the Usage text, though - that is the cleanest way of describing how the presence of a single OPTION alters behavior. src/setuidgid.c:Usage: %s OPTION USER COMMAND [ARGUMENT]...\n\ src/setuidgid.c: or: %s OPTION\n\ Not installed. But this is another case where the Usage could be rendered better (the -g is optional, but can be used multiple times): Usage: %s [SHORT-OPTION]... USER COMMAND [ARGUMENT]... or: %s LONG-OPTION src/sleep.c: or: %s OPTION\n\ 'sleep --help --version' is rejected, but not 'sleep --hel'. src/test.c: or: [ OPTION\n\ Discussed in previous email. src/true.c: or: %s OPTION\n\ One of the few utilities where '/bin/true --hel' already treats --hel as ignored arguments, rather than an abbreviation for --help. src/truncate.c: printf (_("Usage: %s OPTION... FILE...\n"), program_name); Inconsistent formatting. Do we really want to require either -r or -s, or would it make sense to make OPTION optional, in which case the default is -s0? Also, would it make sense to extend this such that: $ echo hi > foo $ truncate --size=0 < foo resizes foo to 0 bytes, by way of ftruncate on stdin? If so, maybe it makes sense to render this as: Usage: truncate [OPTION]... [FILE]... src/unlink.c: or: %s OPTION\n"), program_name, program_name); 'unlink --help --version' is rejected, but not 'unlink --hel'. Should we treat 'unlink --oops' like 'unlink -- --oops'? src/yes.c: or: %s OPTION\n\ 'yes --help --version' is rejected, but 'yes --hel' gives help. Should we treat 'yes --oops' like 'yes -- --oops'? -- Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils