Re: How to get bash to shut up about SIGPIPE?

Linus replied to pj:

I don't believe you did what I did.

The source code for bash, both 2.x and 3.x versions, clearly displays a simpler error message (no line number or redisplay of your script commands) in the case that you set a trap. And I tested both shells on a multiprocessor, to verify that they behaved as I expected, running these silly little scripts.

To labour the point, just now on a multiprocessor near me, the following six line script:

    ======================== begin ========================
    #!/usr/people/pj/etc/bash/bash-3.0/bash
    for x in 1 2
    do
	    trap continue PIPE      # reduce broken pipe screeching
	    cat /etc/termcap        # a big text file
    done | sed 1q
    ========================= end =========================

produced the following three lines of output:

    ======================== begin ========================
    ######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE
    Broken pipe
    Broken pipe
    ========================= end =========================

whereas the following five line script (no trap):

    ======================== begin ========================
    #!/usr/people/pj/etc/bash/bash-3.0/bash
    for x in 1 2
    do
	    cat /etc/termcap        # a big text file
    done | sed 1q
    ========================= end =========================

produced the following three __noisier__ lines of output:

    ======================== begin ========================
    ######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE
    foo: line 2: 11663 Broken pipe             cat /etc/termcap
    foo: line 2: 11665 Broken pipe             cat /etc/termcap
    ========================= end =========================

No no no. You didn't read the code or the comment ;). That or my code and comment were both unclear ... far more likely.

The following line noise is not plagarized from last years Obfuscated Perl Contest:

    ( ( (
	...
    ) 1>&3 ) 2>&1 | grep -vxF 'Broken pipe' 1>&2 ) 3>&1

It's the magic shell incantation to run grep only on the stderr stream, while passing through the stdout stream untouched. Even on the stderr stream, it only zaps lines that are exactly the eleven characters 'Broken pipe' (plus newline).

Now there we agree. I might speculate that they were trying to get an early lead in the Linus Git of the Year contest. But this is relatively mild compared to some of the crap I've seen on other projects I won't name here. So I too am at a loss to know why.