Re: EPIPE in standard utils ([issue41])

[Tom Lord]

       I wonder if there isn't a race condition here: the error return being
       processed before the signal is delivered.  Certainly the return has to
       occur before the signal is delivered or else you'd expect the system
       call to return an EINTR -- so if soon after the return you spew on
       stderr, you get the losing behavior described here.   I admit I'm not
       too clear on what would defer a signal delivery beyond a subsequent
       `write(2)' to stderr -- but it's not unimaginable by any means.


Oh hell ... other simple explanation: the shell is execing `sed' with
SIGPIPE ignored.

But the implications are the same: utils such as sed shouldn't rely on
`SIGPIPE' to bring about their demise;  should treat EPIPE errors
specially (at _least_ not spewing on stderr); and, at least arguably,
should exit with 0 status on EPIPE to an output file.


-t