Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake <address@hidden> 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.