bug#33468: A bug with yes and --help

[Eric Blake]

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