Eric Blake <e...@byu.net> wrote: > 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
Sure. > 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? I'd rather not. Otherwise, basename --h3lp would not give a diagnostic, and "unlink --he" would try to unlink an unlikely file. In each of those cases, the result would be too "surprising". > 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 --. Good catch. > Meanwhile, should we treat "chroot --oops" like "chroot -- --oops"? Probably not. Same reasoning as above. > src/dd.c: or: %s OPTION\n\ > src/dirname.c: or: %s OPTION\n\ > src/expr.c: or: %s OPTION\n\ > src/factor.c: or: %s OPTION\n\ > src/hostname.c: or: %s OPTION\n\ > src/link.c: or: %s OPTION\n"), program_name, program_name); > src/nohup.c: or: %s OPTION\n\ > src/printenv.c: or: %s OPTION\n\ > src/sleep.c: or: %s OPTION\n\ > src/unlink.c: or: %s OPTION\n"), program_name, program_name); > src/yes.c: or: %s OPTION\n\ same as above. > Unlike expr, 'factor --help --version' works. Consistency would be nice. > 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] Good idea. > 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. Yes, printf is a special case. > 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 Yes, that's better. > 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. yes, this is another beaten-to-death exception ;-) > 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]... I'll let Pádraig field this one. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils