On 02/15/2015 01:48 PM, Chet Ramey wrote: > On 2/13/15 12:19 PM, Pádraig Brady wrote: >> I was expecting bash to handle SIGPIPE specially here, >> as in this context it's informational rather than an indication of error. > > I don't agree. It's a fatal signal whose default disposition is to > terminate a process, which is exactly what happens in your example.
The purpose of pipefail is to make the shell indicate when something has gone wrong anywhere in a pipeline. For most programs, SIGPIPE does not indicate that something went wrong. Instead, SIGPIPE is expected behavior. When pipefail spuriously reports expected behavior as an error, Bash comes less useful. > You might consider trapping or ignoring SIGPIPE in situations where it > might be an issue. If I were emperor of the world, I would make SIGPIPE's SIG_DFL action terminate the process with exit status 0. But POSIX says we can't do that. Even locally, I make my system do that without kernel surgery. It's also not reasonable to modify every program that might be part of a pipeline so that it exits successfully on EPIPE. Making Bash treat SIGPIPE death as success is the next best option.
signature.asc
Description: OpenPGP digital signature
