[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: option abbreviation exceptions
From: |
Jim Meyering |
Subject: |
Re: option abbreviation exceptions |
Date: |
Mon, 29 Dec 2008 18:22:55 +0100 |
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.
- Suggestion for rmdir, Adam Jimerson, 2008/12/27
- Re: Suggestion for rmdir, Eric Blake, 2008/12/27
- Re: Suggestion for rmdir, Adam Jimerson, 2008/12/28
- Re: Suggestion for rmdir, Eric Blake, 2008/12/27
- Re: Suggestion for rmdir, Jim Meyering, 2008/12/27
- option abbreviation exceptions (was: Suggestion for rmdir), Eric Blake, 2008/12/29
- Re: option abbreviation exceptions, Eric Blake, 2008/12/29
- Re: option abbreviation exceptions,
Jim Meyering <=
- Re: option abbreviation exceptions, Pádraig Brady, 2008/12/30
- Re: option abbreviation exceptions, Eric Blake, 2008/12/30
- Re: option abbreviation exceptions, Jim Meyering, 2008/12/29