Re: option abbreviation exceptions

[Eric Blake]

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