== A _bash_ irritation Presented in illustrated form: ; cat foo #!/bin/sh cat "$@" ; ./foo /etc/termcap | sed 1q >/dev/null ./foo: line 2: 3632 Broken pipe cat "$@" This behavior is new in Bash 2, as far as I know. I find it extremely irritating, because programs having broken pipes is *perfectly normal* in Unix. Many filters and so on don't consume all of their input, and no other implementation of the Bourne shell reports this (as far as I know). (I would not mind so much if this was only reported for interactive sessions; it is that _bash_ spews out this message in shell scripts that irritates me so much.) As the [[BASH FAQ http://cnswww.cns.cwru.edu/~chet/bash/FAQ]] covers in its section E2, this *can* be disabled when people compile bash. Debian apparently usually compiles bash this way (good for them); Red Hat does not (sigh). Of course this solution only helps people who can recompile and reinstall bash on all of the systems they want their shell scripts to run nicely on. You can muzzle much of the verbosity of this by adding a do-nothing _trap_ for SIGPIPE. Unfortunately you can't get it all; the best you can do is: ; cat foo2 #!/bin/sh trap ':' 13; cat "$@"; exit 0 ; ./foo2 /etc/termcap | sed 1q >/dev/null Broken pipe The message comes from _bash_ itself. If you _trap_ signal 13 to nothing at all, bash will set SIGPIPE to 'ignored' (_[[SIG_IGN|]]_) for all of the processes in the pipe, which will cause them to see write errors instead of dying when the pipe breaks, which gets you: ; cat foo3 #!/bin/sh trap '' 13; cat "$@"; exit 0 ; ./foo3 /etc/termcap | sed 1q >/dev/null cat: write error: Broken pipe Which error message you prefer is a matter of taste. I tend to go for the _foo3_ case, because at least then I can remember why I am getting these strange messages (and grind my teeth about it yet again).