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
