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

Linus replied to pj:
> > Code Sample 2:
> > ...
> Didn't change anything for me. Same thing.

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 =========================



> > just that noise, leaving whatever else was on stdout and/or stderr
> > unscathed:
> 
> It will also grep out any occurrence of "Broken pipe", so if we're talking 
> about a kernel changelog, where we fix a pipe bug...

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).

> I don't know why the bash people have that stupid pipe reporting in the 

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.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html