Stephane Chazelas via austin-group-l at The Open Group dixit:
>2021-06-28 20:01:03 +0700, Robert Elz:
>[...]
I see significant support here for my interpretation of this.
And I’d probably even be annoyed if it shows strerror(EPIPE)…
But…
>> | so users were using >&- instead to silence output.
… let’s please stop that consideration. Closing stdin/stdout/stderr
is A Bad Thing™ (especially as other opened files can AND WILL reuse
the fd numbers 0/1/2, and yes I’ve seen that happen) and totally not
supported.
What’s currently left of Vincent’s issue is that the utility tries
to write to its stdout¹ which the shell has connected to something
that does not accept writes: /dev/full on systems that have it, an
existing file on a full or readonly filesystem, some pipe that was
closed, etc.
① Worse, stderr — in which case we can’t even show the diagnostic,
and possibly accumulate more errors.
>My Solaris test cases corrected to use EPIPE instead of EBADF:
>
>$ (trap "" PIPE; sleep 1; /usr/xpg4/bin/sh -c 'grep root /etc/passwd; echo
>"$?" >&2') | :
>0
>$ (trap "" PIPE; sleep 1; /bin/sh -c 'grep root /etc/passwd; echo "$?" >&2') |
>:
>0
>$ (trap "" PIPE; sleep 1; /bin/sh -c 'pwd; echo "$?" >&2') | :
>0
That goes with your statement of…
>On Solaris 11 (certified as compliant):
… which makes me think that (besides significant vocal support on
this list) there’s significant precedent for this real-existing,
historically-founded, behaviour of not having to check for all
kinds of stdout/stderr write errors for utilities “like that” (I’d
expect text editors, for example, to still show errors of course),
the boundary of “like that” probably being that it’s not in pwd’s
domain to care about or set up its output (merely using stdout),
whereas text editors deal with filenames and open(2) etc. directly.
On a more technical note, changing this would be *extremely* tricky.
The shell implementation doesn’t use stdio necessarily, and sprinkling
checks all over the code will make it less maintainable, slower, and
is bound to still miss some, plus there’s the question of what to do
for each code location. In some cases, the failure to write can IMHO
totally be ignored if the tool otherwise completes its job. Finding
out which these are is also going to be tricky.
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
