git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org, pasky@ucw.cz
Subject: Re: How to get bash to shut up about SIGPIPE?
Date: Fri, 29 Apr 2005 17:22:35 -0700	[thread overview]
Message-ID: <20050429172235.21c1af10.pj@sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org>

> bash is being an ass about SIGPIPE

You have a multiprocessor, don't you.

The following silly little shell script will provoke the bash SIGPIPE
complaint reliably on a multiprocessor.  It writes a big file, twice,
from a for-loop in a separate bash subshell through a pipe to a command
that exits after seeing one line.

Code Sample 1:

    #!/bin/bash
    for x in 1 2
    do
        cat /etc/termcap	# a big text file
    done | sed 1q

Adding a right trap _inside_ the shell loop that is _before_ the pipe
will reduce the verbosity of the complaint substantially (not show the
line number and text for each command inside the loop that is killed by
the SIGPIPE; rather just show the simple "Broken pipe" error message):

Code Sample 2:

    #!/bin/bash
    for x in 1 2
    do
	trap continue PIPE	# reduce broken pipe screeching
	cat /etc/termcap	# a big text file
    done | sed 1q

Then wrapping the entire pipeline (now that the bogus output is a
constant "Broken pipe" string) in the following manner will filter out
just that noise, leaving whatever else was on stdout and/or stderr
unscathed:

Code Sample 3:

    #!/bin/bash
    ( ( (
	for x in 1 2
	do
		trap continue PIPE      # reduce broken pipe screeching
		cat /etc/termcap        # a big text file
	done | sed 1q
    ) 1>&3 ) 2>&1 | grep -vxF 'Broken pipe' 1>&2 ) 3>&1

The following patch to bash jobs.c will enable "Code Sample 2" to do the
right thing, without depending (so much) on the DONT_REPORT_SIGPIPE
compile time flag.  With this patch, you don't have to go all the way to
the baroque code in "Code Sample 3" to shut bash up.  Just a well placed
trap is sufficient.

Whether or not this is actually worth persuing (or was even worth
reading ;) I don't know.

--- jobs.c.orig 2001-03-26 10:08:24.000000000 -0800
+++ jobs.c      2005-04-29 17:09:44.294763496 -0700
@@ -2686,11 +2686,8 @@ notify_of_job_status ()
                }
              else if (IS_FOREGROUND (job))
                {
-#if !defined (DONT_REPORT_SIGPIPE)
-                 if (termsig && WIFSIGNALED (s) && termsig != SIGINT)
-#else
-                 if (termsig && WIFSIGNALED (s) && termsig != SIGINT && termsig != SIGPIPE)
-#endif
+                 if (termsig && WIFSIGNALED (s) && termsig != SIGINT &&
+                   (termsig != SIGPIPE || signal_is_trapped (termsig) == 0))
                    {
                      fprintf (stderr, "%s", strsignal (termsig));



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

  parent reply	other threads:[~2005-04-30  0:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-28 18:28 How to get bash to shut up about SIGPIPE? Linus Torvalds
2005-04-28 19:03 ` Rene Scharfe
2005-04-28 19:21   ` Linus Torvalds
2005-04-28 20:13     ` Rene Scharfe
2005-04-28 20:27     ` Ryan Anderson
2005-04-28 20:47       ` Linus Torvalds
2005-05-01 12:07       ` Herbert Xu
2005-05-01 15:51         ` David A. Wheeler
2005-05-02 16:10           ` Paul Jackson
2005-05-04  2:30             ` David A. Wheeler
2005-05-04  2:50               ` Linus Torvalds
2005-05-04  8:26                 ` Herbert Xu
2005-04-28 21:31 ` Edgar Toernig
2005-04-28 22:16   ` Linus Torvalds
2005-04-29  1:00 ` Joshua T. Corbin
2005-04-30  0:22 ` Paul Jackson [this message]
2005-04-30  2:59   ` Linus Torvalds
2005-04-30  6:29     ` Paul Jackson
2005-04-30 11:04       ` Rene Scharfe
2005-05-02 22:17         ` Paul Jackson
2005-05-02 23:17         ` Petr Baudis
2005-05-03  1:44           ` Paul Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050429172235.21c1af10.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).