Re: purpose of *-safer?

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> Eric Blake wrote:
>> POSIX requires [n]>&- and [n]<&- redirection operators to close
>> the respective stream, even when n is 0, 1, or 2.  POSIX allows an
>> implementation to supply replacement file descriptors when exec'ing a
>> setuid or setgid program.  But in the normal case, implementations really
>> do allow you to start life with any of the three standard streams closed.
>
> Thanks for explaining. I wasn't aware that sh has built-in operators
> for doing this.
>
>> that doesn't mean GNU programs can't be robust against it.
>
> OK, but what is the correct behaviour? Signal an error?
>
>   $ cp --help >&- ; echo $?
>   cp: write error: Bad file descriptor
>   1
>
> or treat it like /dev/null?
>
>   $ cp --help >&- ; echo $?
>   0

That's easy:

Don't ever hide a conceptual write failure.
Reporting the error is the desired behavior.
It's no accident that cp (and all other coreutils) work the way they do.

In your simple example, it's "obvious" what is intended,
and you might argue that masking the error is better,
but what if a similar command fails as part of a script
that is inadvertently run without a stdout file descriptor?
The user of the script should be able to expect a non-zero
exit status and, if possible, a diagnostic.