Date: Mon, 28 Jun 2021 10:03:39 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<[email protected]>
Message-ID: <20210628090339.GA13976@localhost>
| The (builtin) pwd utility got an error when it tried to write() to
| standard output.
But did it "encounter" the error? Generally to encounter something
you need to be looking for it (except in the case where the issue jumps
up and bites you). If you don't look, you don't encounter it, you simply
pass by.
| I suppose you could argue that ENOSPC can be
| considered recoverable since some space could be freed,
A more blatant case would be
pwd | (exit 0)
If SIGPIPE is not trapped, that one jumps and bites - but no-one is
ever told about it (shells don't generally print errors about processes
in pipes that encounter SIGPIPE) and if SIGPIPE is being ignored
trap '' PIPE; pwd | (exit 0)
do you really want pwd to say "Broken pipe" ?
That one certainly isn't recoverable, so that way out is not available,
no matter how hard pwd tries.
It has been tradition, for a very long time, for writes on stdout to
have errors ignored - particularly in a case like this, where because
of the redirection, stdout is probably buffered, and not a lot is
written, so the actual write that encounters the error most likely
happens during exit() processing (flushing stdio buffers).
If there was actually anything in the standard (for any process, that
is, ignoring Don's comments about the specific requirements for pwd)
which (seemed to) require processes to fflush(stdout) and check for
errors before exiting, then that would need to be fixed, because that
simply is not the way that (most) applications behave (some do, when it
is important to them, which is fine).
But as long as we can rely on the meaninglessness of that "encountered"
to allow unnoticed errors to be ignored, nothing actually needs to be
done.
kre
