On Tue, Jun 3, 2014 at 7:23 AM, Jim Meyering <[email protected]> wrote: > On Tue, Jun 3, 2014 at 5:16 AM, Pádraig Brady <[email protected]> wrote: >> On 06/03/2014 01:12 PM, Eric Blake wrote: > ... >>> Oh, good point. Maybe it's better to consistently have --help/--version >>> return status 0 (we successfully printed output) or 1 (we encountered >>> write failure) regardless of the program being executed (which means >>> true is doing it right, and 'false --version' is the odd man out, >>> opposite to what the most recent patch proposal does). I'd wait for >>> Paul and/or Jim to weigh in on this, since they made the decisions >>> behind the current unpatched behavior. >> >> My slight preference is to change true to be consistent, >> as then it's consistent on all implementations, not >> just within coreutils. I.E. the following would now hold everywhere: >> >> true --help > /dev/full && echo always ok > > My rationale in making true --help > /dev/full diagnose the error was > to consistently enable detection of write failure. With --help and > --version, we are outside the bounds of POSIX spec. The amended > spec is that the program must print the requested output and exit > with status reflecting success or failure of the write. Without that > check, someone attempting to write-then-parse that help output > would be unable to distinguish the successful case and one in which > the write hit e.g., EIO or ENOSPC. > > IMHO, there is no reason to ignore such a write error. > Hence, false --version and false --help (currently always failing) are the > ones I would change, so that they succeed when there is no write error.
On second thought, I don't like the idea of making false --help/--version exit successfully. Maybe, gasp, we should just make true and false the exception from GNU's accept --help/--version philosophy, and simply exit 0/1, ignoring *all* options. This would add minor complication to true.1 and false.1 man page generation, but it would not be hard to work around.
