On 11/26/18 2:24 AM, Bernhard Voelker wrote:
E.g. for 'yes', all of the following successfully detecting
the --version option (and likewise for --help):
$ src/yes --version
$ src/yes hello --version
$ src/yes hello --version world
$ src/yes --version hello
$ src/yes hello --v hello -- a b
As long as it is still possible to output the string verbatim, which it
should be with:
$ src/yes -- --version | head -1
--version
$ src/yes -- hello --version | head -1
hello --version
etc.
WDYT?
GCS is clear that 'yes --version more' should output a help message
right away, rather than trying to go on to process the 'more' argument,
barring any strong reason that it should not ('echo' and 'test' being
two utilities that have strong reasons for being exceptions, due to
their standardized requirements). Forwarding utilities, like 'nohup' or
'env', should not reorder command line arguments, so there, it is harder
to argue whether 'env --unknown --help' should error that '--unknown' is
bad or succeed in giving help; but 'env utility --help' should NOT print
the env-specific help. Even so, with forwarding apps, GCS is clear that
'env --help --unknown' should prefer to give help rather than
complaining about --unknown. When command-line option reordering is
permitted (GCS recommends it for all non-forwarding apps), then 'yes
more --version' should output help the same as 'yes --help more', rather
than behave like non-reordering 'yes -- more --version'.
So it really boils down to an audit of which utilities are forwarding
apps (and must not reorder arguments), which utilities have special
behavior based on number of arguments (echo, test, ...), and a question
of whether unknown options should be diagnosed up front. I think your
proposal to change 'yes' makes sense, although I haven't closely thought
about the ramifications of the other utilities you are touching.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org