Adam (midendian) wrote in unixhistory,


This isn't related to the big-picture of UNIX history, but it is UNIX related and something that's bugged me for many years, and someday I hope to understand why it was done.

All of the signals (see signal(7)) make sense to me as signals. But there's one, and it's a really old one as far as I know, that makes far less sense than the others: SIGPIPE. Why is this i/o condition so important that, by default, programs need to die because of it? It feels like there was a race condition in some code somewhere (probably in a shell) that was easier to solve with a terminating signal than by more robust coding. It's also redundant, as the write() will fail with EPIPE.

So, anyone know the story behind SIGPIPE? (A google for "SIGPIPE history" results in the change logs for hundreds of programs with SIGPIPE-related bugs, most of which used the fix of "ignore SIGPIPE".)
  • Post a new comment


    default userpic