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

[Eric Blake]

On 2/22/19 1:46 AM, Bernhard Voelker wrote:

>> Finally, I documented the change in 'yes' in NEWS regarding:
>>
>>   $ yes a -- b | head -n1
>>   a -- b
>> vs.
>>   $ src/yes a -- b | head -n1
>>   a b
> 
> What about putting 'yes' into the 'nohup' category?  I mean, we have
> the SCAN_ALL flag in our new function, so why not simply use it?

My opinion: SCAN_ALL should ONLY be used by forwarding apps (nohup, env,
nice, ...). yes is not a forwarding app. GNU Coding Standards demand
that unless you have a strong reason to forbid option reordering (and
being a forwarding app is such a strong reason), then you should default
to allowing argument reordering, which means this is a bug-fix for 'yes'
and not a regression.


> That makes:
> 
>   $ src/yes a -- b | sed 1q
>   a -- b
> 
> and also recognizing --help when other arguments are following:
> 
>   $ src/yes --help a -- b | sed 1q
>   Usage: src/yes [STRING]...

But breaks:

$ src/yes a --help

into outputting "a --help" infinitely instead of giving help, which was
the whole point of this exercise.

> 
> That is actually our intention, no?
> WDYT?

Bad idea, for the reasons given above. Leave it as-is, with the change
in yes behavior being an intentional bug fix.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org