Re: true,false: --version,--help exit code

[Jim Meyering]

On Tue, Jun 3, 2014 at 7:23 AM, Jim Meyering <address@hidden> wrote:
> On Tue, Jun 3, 2014 at 5:16 AM, Pádraig Brady <address@hidden> 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.