2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group: [...] > > If in general, then forget it - the users would lynch you (you'd probably > > suicide first) if you successfully caused that to happen. > > No they wouldn't. The only reason to set SIGPIPE to be ignored is > because you want EPIPE error conditions to be diagnosed instead of > causing the process to terminate. [...]
Should SIGPIPE cause the *shell* process to terminate by the way when a builtin tries to write to a broken pipe (the reverse problem of the one being discussed here)? We see that: ( trap '' PIPE sleep 1 set -o errexit -o xtrace pwd pwd ) | : "incorrectly" calls pwd twice with some pwd implementations (builtin or not) as they fail to report the write error in their exit status. But conversely: ( sleep 1 set +o errexit -o xtrace pwd pwd ) | : Calls pwd only once with most shell implementations (all those where pwd is builtin). Is that allowed? If yes, and considering that the list of commands that are builtin varies from shell to shell, that also contributes to making the behaviour unpredictable upon write errors. -- Stephane
