Robert Elz wrote, on 28 Jun 2021: > > 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.
The error occurred, and because of it the utility did not do what it is supposed to do. At the very least this means the exit status must not be zero (because zero indicates "successful completion", i.e. it successfully did what it is supposed to do). Given a non-zero exit status (which for pwd means "An error occurred"), the general rule is that a diagnostic message to stderr is also required. > | 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" ? If write() fails with EPIPE then yes I would expect pwd to write a diagnostic message and exit with non-zero status. > 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). You are talking about pre-POSIX tradition. The rules in POSIX.2 should have put an end to that ancient dodgy behaviour when systems were updated to conform to POSIX. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
