From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: When I run "grep" command, and pipe the output to stdout to see part of the returned result, I always get the following error: cassiopeia 97% grep '>target' HG-U95A_target | head grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe (...repeat many many times) If I pipe the output to a file, it works fine. Or when I switch to bach, it also works. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.grep a frequently appeared word from a long file and pipe it to `head` command Actual Results: grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe Expected Results: return the lines with matching pattern Additional info: The problem may be more rampant, for when I tried to see the man page of "tcsh", I got the following error: cassiopeia 98% man tcsh gunzip: stdout: Broken pipe gunzip: stdout: Broken pipe grotty:<standard input>:70160:fatal error: output error I never had this problem till I upgraded to RedHat 8.0. And my officemate who also runs RedHat 8.0 has the same problem when I test it out on his machine.
I see this problem too, and have a bit more data on it. It only happens in my experience if you use tcsh, rather than bash, and only if you run tcsh directly from /etc/passwd, and not from within a bash. Also, you only see the problem on an xterm or gnome-terminal -- not on a virtual console. And you don't see the problem on an xterm if you log into the computer via ssh, or even if you start up an xterm from within the ssh, even if you are ssh'ing to the same computer. You can see the problem by doing % man man and then typing "q" at more or by doing % cat /etc/termcap | /bin/more and then typing "q" at more.
With tcsh-6.13-1 I can't reproduce this even after explicitly enabling SIGPIPE before executing tcsh. The code in recent releases (6.12, 6.13 explicitly skips output of the SIGPIPE message for processes whose standard output is directed in a pipe.