{"thread":{"id":"377","subject":"How to get bash to shut up about SIGPIPE?","startedAt":"2005-04-28T18:28:40Z","lastAt":"2005-05-04T08:26:25Z","messageCount":22,"participants":["Linus Torvalds","Rene Scharfe","Ryan Anderson","Edgar Toernig","Joshua T. Corbin","Paul Jackson","Herbert Xu","David A. Wheeler","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2062","messageId":"Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org","threadId":"377","inReplyTo":null,"subject":"How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T18:28:40Z","receivedAt":"2005-04-28T18:28:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nRight now my major gripe with cogito is \"cg-log\" (which is actually the \nonly command I use right now, everything else I just do by hand with the \nraw git archive) is that bash is being an ass about SIGPIPE, and when I \nonly look at the top part of the log, ie I do something like:\n\n\ttorvalds@ppc970:~/src/cogito> git log | head\n\nit spews out the ten first lines of the log, and then it spews about a \nmillion lines (well, 20, but anyway) of crap:\n\n\t/home/torvalds/bin/cg-log: line 87: 6338 Done echo -n $color$key $rest\n\t 6339 Broken pipe | sed \"s/>.*/> ${pdate/+0000/$tz}/\"\n\t/home/torvalds/bin/cg-log: line 87: 6328 Done cat-file commit $commit\n\t 6329 Broken pipe | while read key rest; do\n\t case \"$key\" in \n\t \"author\" | \"committer\")\n\t if [ \"$key\" = \"author\" ]; then\n\t color=\"$colauthor\";\n\t else\n\t color=\"$colcommitter\";\n\t fi; date=(${rest#*> }); sec=${date[0]}; tz=${date[1]}; dtz=${tz/+/}; lsec=$(expr $dtz / 100 \\* 3600 + $dtz % 100 \\* 60 + $sec); pdate=\"$(date -Rud \"1970-01-01 UTC + $lsec sec\" 2>/dev/null)\"; if [ \"$pdate\" ]; then\n\t echo -n $color$key $rest | sed \"s/>.*/> ${pdate/+0000/$tz}/\"; echo $coldefault;\n\t else\n\t echo $color$key $rest $coldefault;\n\t fi\n\t ;;\n\t \"\")\n\t echo; sed -re '\n\t / \n\t*Signed-off-by:.*/Is//'$colsignoff'&'$coldefault'/\n\t s/./ &/\n\t '\n\t ;;\n\t *)\n\t echo $colheader$key $rest $coldefault\n\t ;;\n\t esac;\n\tdone\n\nwhich is just incredibly annoying, since it makes the ten lines I actually \n_wanted_ to get scroll off the screen..\n\nDamn bash. What's the magic incantation that says SHUT UP!?\n\n\t\tLinus\n"},{"id":"2065","messageId":"42713379.7080107@lsrfire.ath.cx","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2005-04-28T19:03:21Z","receivedAt":"2005-04-28T19:03:21Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Linus Torvalds schrieb:\n> Right now my major gripe with cogito is \"cg-log\" (which is actually\n> the only command I use right now, everything else I just do by hand\n> with the raw git archive) is that bash is being an ass about SIGPIPE,\n> and when I only look at the top part of the log, ie I do something\n> like:\n> \n> torvalds@ppc970:~/src/cogito> git log | head\n\nI think you misspelled \"cg-log\". :-D\n\nDoing \"cg-log | head\" gives me 10 lines of log and nothing else. Maybe\nthe problem has been fixed between 0.7 and the current version I'm using\n(commit ID 49612c471eebd26efe926a71752e254c1cdc382d)?\n\nRene\n"},{"id":"2070","messageId":"Pine.LNX.4.58.0504281217100.18901@ppc970.osdl.org","threadId":"377","inReplyTo":"42713379.7080107@lsrfire.ath.cx","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T19:21:26Z","receivedAt":"2005-04-28T19:21:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Rene Scharfe wrote:\n> \n> I think you misspelled \"cg-log\". :-D\n\nMy fingers have a hard time learning new patterns, so I've got:\n\n\ttorvalds@ppc970:~/git> cat ~/bin/git \n\t#!/bin/sh\n\tcmd=\"cg-$1\"\n\tshift\n\t$cmd \"$@\"\n\nuntil my fingers learn the new thing.\n\n> Doing \"cg-log | head\" gives me 10 lines of log and nothing else. Maybe\n> the problem has been fixed between 0.7 and the current version I'm using\n> (commit ID 49612c471eebd26efe926a71752e254c1cdc382d)?\n\nno, this is current as of an hour ago, same head you have.\n\nIt's a bash-specific thing, and depends on how you compiled bash.\n\nDefining \"DONT_REPORT_SIGPIPE\" in config-top.h when building bash gets rid \nof it, but I really don't want to rebuild bash just because of this ;)\n\n\t\tLinus\n"},{"id":"2073","messageId":"427143E5.4080505@lsrfire.ath.cx","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281217100.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2005-04-28T20:13:25Z","receivedAt":"2005-04-28T20:13:25Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Linus Torvalds schrieb:\n> \n> On Thu, 28 Apr 2005, Rene Scharfe wrote:\n> \n>>I think you misspelled \"cg-log\". :-D\n> \n> \n> My fingers have a hard time learning new patterns, so I've got:\n> \n> \ttorvalds@ppc970:~/git> cat ~/bin/git \n> \t#!/bin/sh\n> \tcmd=\"cg-$1\"\n> \tshift\n> \t$cmd \"$@\"\n\nAs a workaround, add this line after the shift to suppress the ugly\nmessages:\n\n\t[ \"$cmd\" = cg-log ] && exec 2>/dev/null\n\n> Defining \"DONT_REPORT_SIGPIPE\" in config-top.h when building bash gets rid\n> of it, but I really don't want to rebuild bash just because of this ;)\n\nYes, I just compiled it and in the version from gnu.org this defaults to\nnot being defined. Man, am I glad my distro uncommented that line. :-)\n\nLooking briefly at the source there doesn't seem to be a way to turn it\noff besides this compile time setting. I really wonder why..\n\nRene\n"},{"id":"2074","messageId":"20050428202739.GE30308@mythryan2.michonline.com","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281217100.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-04-28T20:27:39Z","receivedAt":"2005-04-28T20:27:39Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Apr 28, 2005 at 12:21:26PM -0700, Linus Torvalds wrote:\n> On Thu, 28 Apr 2005, Rene Scharfe wrote:\n> > \n> > I think you misspelled \"cg-log\". :-D\n> \n> My fingers have a hard time learning new patterns, so I've got:\n> \n> \ttorvalds@ppc970:~/git> cat ~/bin/git \n> \t#!/bin/sh\n> \tcmd=\"cg-$1\"\n> \tshift\n> \t$cmd \"$@\"\n> \n> until my fingers learn the new thing.\n> \n> > Doing \"cg-log | head\" gives me 10 lines of log and nothing else. Maybe\n> > the problem has been fixed between 0.7 and the current version I'm using\n> > (commit ID 49612c471eebd26efe926a71752e254c1cdc382d)?\n> \n> no, this is current as of an hour ago, same head you have.\n> \n> It's a bash-specific thing, and depends on how you compiled bash.\n> \n> Defining \"DONT_REPORT_SIGPIPE\" in config-top.h when building bash gets rid \n> of it, but I really don't want to rebuild bash just because of this ;)\n\nDebian's bash seems to have that set, so it's a bit hard for me to test\n(I don't really have any non-Debian machines around these days for some\nreason.)\n\nTry adding \"set -e\" to the beginning of cg-log.\n\nThat may cause some *other* problems, but I think it will fix this\nproblem.\n\n-- \n\nRyan Anderson\n sometimes Pug Majere\n"},{"id":"2076","messageId":"Pine.LNX.4.58.0504281339530.18901@ppc970.osdl.org","threadId":"377","inReplyTo":"20050428202739.GE30308@mythryan2.michonline.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T20:47:15Z","receivedAt":"2005-04-28T20:47:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Ryan Anderson wrote:\n> \n> Try adding \"set -e\" to the beginning of cg-log.\n\nNope. I actually downloaded bash-3.0, and it literally seem sto be \nimpossible to get bash to not do it. \n\nIt has some noise there about signal trapping, but that doesn't actually\nseem to work.\n\n\t\tLinus\n"},{"id":"2085","messageId":"20050428233104.3e606ba9.froese@gmx.de","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2005-04-28T21:31:04Z","receivedAt":"2005-04-28T21:31:04Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Linus Torvalds wrote:\n>\n> Damn bash. What's the magic incantation that says SHUT UP!?\n\nTry this:\n\n+\t{ set -e; trap 'exit 1' SIGPIPE\n\t$revls | $revsort | while read time commit parents; do\n\t\t[ \"$revfmt\" = \"rev-list\" ] && commit=\"$time\"\n\t\t...\n-\tdone | ${PAGER:-less} ${PAGER_FLAGS:--R}\n+\tdone; } | ${PAGER:-less} ${PAGER_FLAGS:--R}\n\nCiao, ET.\n"},{"id":"2102","messageId":"Pine.LNX.4.58.0504281515330.18901@ppc970.osdl.org","threadId":"377","inReplyTo":"20050428233104.3e606ba9.froese@gmx.de","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T22:16:44Z","receivedAt":"2005-04-28T22:16:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Edgar Toernig wrote:\n> \n> Try this:\n\nNope. No difference what-so-ever.\n\nSide note: it's timing-dependent, so apparently especially on SMP, \nsometimes it doesn't complain, and then I think soemthing worked. Then I \ntry again, and it's always back.\n\nI've made a bug-report against bash.\n\n\t\tLinus\n"},{"id":"2114","messageId":"200504282100.53567.jcorbin@wunjo.org","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Joshua T. Corbin","fromEmail":"jcorbin@wunjo.org","sentAt":"2005-04-29T01:00:53Z","receivedAt":"2005-04-29T01:00:53Z","isPatch":false,"sender":{"key":"jcorbin@wunjo.org","avatar":null},"body":"On 28 April 2005 14:28, you wrote:\n> Right now my major gripe with cogito is \"cg-log\" (which is actually the\n> only command I use right now, everything else I just do by hand with the\n> raw git archive) is that bash is being an ass about SIGPIPE, and when I\n> only look at the top part of the log, ie I do something like:\n\nIf cg-log is all you use, then you could get away with using yagf:\n rsync://node1.wunjo.org/yagf.git\n\nFeatures of cg-log missing in yagf log:\n * colors\n * sigpipe gripes ;)\n * #!/bin/bash (or /usr/bin/env bash)\n * ability to log between two commits with rev-tree (it's a planned feature\n in the near future.)\n\nCheers,\nJosh\n"},{"id":"2221","messageId":"20050429172235.21c1af10.pj@sgi.com","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504281121430.18901@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-30T00:22:35Z","receivedAt":"2005-04-30T00:22:35Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"> bash is being an ass about SIGPIPE\n\nYou have a multiprocessor, don't you.\n\nThe following silly little shell script will provoke the bash SIGPIPE\ncomplaint reliably on a multiprocessor. It writes a big file, twice,\nfrom a for-loop in a separate bash subshell through a pipe to a command\nthat exits after seeing one line.\n\nCode Sample 1:\n\n #!/bin/bash\n for x in 1 2\n do\n cat /etc/termcap\t# a big text file\n done | sed 1q\n\nAdding a right trap _inside_ the shell loop that is _before_ the pipe\nwill reduce the verbosity of the complaint substantially (not show the\nline number and text for each command inside the loop that is killed by\nthe SIGPIPE; rather just show the simple \"Broken pipe\" error message):\n\nCode Sample 2:\n\n #!/bin/bash\n for x in 1 2\n do\n\ttrap continue PIPE\t# reduce broken pipe screeching\n\tcat /etc/termcap\t# a big text file\n done | sed 1q\n\nThen wrapping the entire pipeline (now that the bogus output is a\nconstant \"Broken pipe\" string) in the following manner will filter out\njust that noise, leaving whatever else was on stdout and/or stderr\nunscathed:\n\nCode Sample 3:\n\n #!/bin/bash\n ( ( (\n\tfor x in 1 2\n\tdo\n\t\ttrap continue PIPE # reduce broken pipe screeching\n\t\tcat /etc/termcap # a big text file\n\tdone | sed 1q\n ) 1>&3 ) 2>&1 | grep -vxF 'Broken pipe' 1>&2 ) 3>&1\n\nThe following patch to bash jobs.c will enable \"Code Sample 2\" to do the\nright thing, without depending (so much) on the DONT_REPORT_SIGPIPE\ncompile time flag. With this patch, you don't have to go all the way to\nthe baroque code in \"Code Sample 3\" to shut bash up. Just a well placed\ntrap is sufficient.\n\nWhether or not this is actually worth persuing (or was even worth\nreading ;) I don't know.\n\n--- jobs.c.orig 2001-03-26 10:08:24.000000000 -0800\n+++ jobs.c 2005-04-29 17:09:44.294763496 -0700\n@@ -2686,11 +2686,8 @@ notify_of_job_status ()\n }\n else if (IS_FOREGROUND (job))\n {\n-#if !defined (DONT_REPORT_SIGPIPE)\n- if (termsig && WIFSIGNALED (s) && termsig != SIGINT)\n-#else\n- if (termsig && WIFSIGNALED (s) && termsig != SIGINT && termsig != SIGPIPE)\n-#endif\n+ if (termsig && WIFSIGNALED (s) && termsig != SIGINT &&\n+ (termsig != SIGPIPE || signal_is_trapped (termsig) == 0))\n {\n fprintf (stderr, \"%s\", strsignal (termsig));\n\n\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"2231","messageId":"Pine.LNX.4.58.0504291956030.2296@ppc970.osdl.org","threadId":"377","inReplyTo":"20050429172235.21c1af10.pj@sgi.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-30T02:59:46Z","receivedAt":"2005-04-30T02:59:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 29 Apr 2005, Paul Jackson wrote:\n>\n> > bash is being an ass about SIGPIPE\n> \n> You have a multiprocessor, don't you.\n\nYes. \n\n> The following silly little shell script will provoke the bash SIGPIPE\n> complaint reliably on a multiprocessor.\n\nYup:\n\n\tt: line 5: 3853 Broken pipe cat /etc/termcap\n\tt: line 5: 3855 Broken pipe cat /etc/termcap\n\n> Adding a right trap _inside_ the shell loop that is _before_ the pipe\n> will reduce the verbosity of the complaint substantially (not show the\n> line number and text for each command inside the loop that is killed by\n> the SIGPIPE; rather just show the simple \"Broken pipe\" error message):\n> \n> Code Sample 2:\n> \n> #!/bin/bash\n> for x in 1 2\n> do\n> \ttrap continue PIPE\t# reduce broken pipe screeching\n> \tcat /etc/termcap\t# a big text file\n> done | sed 1q\n\nDidn't change anything for me. Same thing.\n\n> Then wrapping the entire pipeline (now that the bogus output is a\n> constant \"Broken pipe\" string) in the following manner will filter out\n> just that noise, leaving whatever else was on stdout and/or stderr\n> unscathed:\n\nIt will also grep out any occurrence of \"Broken pipe\", so if we're talking \nabout a kernel changelog, where we fix a pipe bug...\n\n> Whether or not this is actually worth persuing (or was even worth\n> reading ;) I don't know.\n\nI don't know why the bash people have that stupid pipe reporting in the \nfirst place, considering that no other shell seems to do it, and everybody \njust wants to shut it up..\n\n\t\tLinus\n"},{"id":"2243","messageId":"20050429232922.03057aba.pj@sgi.com","threadId":"377","inReplyTo":"Pine.LNX.4.58.0504291956030.2296@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-30T06:29:22Z","receivedAt":"2005-04-30T06:29:22Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Linus replied to pj:\n> > Code Sample 2:\n> > ...\n> Didn't change anything for me. Same thing.\n\nI don't believe you did what I did.\n\nThe source code for bash, both 2.x and 3.x versions, clearly displays a\nsimpler error message (no line number or redisplay of your script\ncommands) in the case that you set a trap. And I tested both shells on\na multiprocessor, to verify that they behaved as I expected, running\nthese silly little scripts.\n\nTo labour the point, just now on a multiprocessor near me, the following\nsix line script:\n\n ======================== begin ========================\n #!/usr/people/pj/etc/bash/bash-3.0/bash\n for x in 1 2\n do\n\t trap continue PIPE # reduce broken pipe screeching\n\t cat /etc/termcap # a big text file\n done | sed 1q\n ========================= end =========================\n\nproduced the following three lines of output:\n\n ======================== begin ========================\n ######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE\n Broken pipe\n Broken pipe\n ========================= end =========================\n\n\nwhereas the following five line script (no trap):\n\n ======================== begin ========================\n #!/usr/people/pj/etc/bash/bash-3.0/bash\n for x in 1 2\n do\n\t cat /etc/termcap # a big text file\n done | sed 1q\n ========================= end =========================\n\n\nproduced the following three __noisier__ lines of output:\n\n ======================== begin ========================\n ######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE\n foo: line 2: 11663 Broken pipe cat /etc/termcap\n foo: line 2: 11665 Broken pipe cat /etc/termcap\n ========================= end =========================\n\n\n\n> > just that noise, leaving whatever else was on stdout and/or stderr\n> > unscathed:\n> \n> It will also grep out any occurrence of \"Broken pipe\", so if we're talking \n> about a kernel changelog, where we fix a pipe bug...\n\nNo no no. You didn't read the code or the comment ;). That or my code\nand comment were both unclear ... far more likely.\n\nThe following line noise is not plagarized from last years Obfuscated\nPerl Contest:\n\n ( ( (\n\t...\n ) 1>&3 ) 2>&1 | grep -vxF 'Broken pipe' 1>&2 ) 3>&1\n\nIt's the magic shell incantation to run grep only on the stderr stream,\nwhile passing through the stdout stream untouched. Even on the stderr\nstream, it only zaps lines that are exactly the eleven characters\n'Broken pipe' (plus newline).\n\n> I don't know why the bash people have that stupid pipe reporting in the \n\nNow there we agree. I might speculate that they were trying to get an\nearly lead in the Linus Git of the Year contest. But this is relatively\nmild compared to some of the crap I've seen on other projects I won't\nname here. So I too am at a loss to know why.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"2247","messageId":"20050430110410.GA25322@lsrfire.ath.cx","threadId":"377","inReplyTo":"20050429232922.03057aba.pj@sgi.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2005-04-30T11:04:10Z","receivedAt":"2005-04-30T11:04:10Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"On Fri, Apr 29, 2005 at 11:29:22PM -0700, Paul Jackson wrote:\n> Linus replied to pj:\n> > > Code Sample 2:\n> > > ...\n> > Didn't change anything for me. Same thing.\n> \n> I don't believe you did what I did.\n> \n> The source code for bash, both 2.x and 3.x versions, clearly displays a\n> simpler error message (no line number or redisplay of your script\n> commands) in the case that you set a trap. And I tested both shells on\n> a multiprocessor, to verify that they behaved as I expected, running\n> these silly little scripts.\n\nI don't have a multiprocessor and I see the same. Are you sure it's SMP\ndependant?\n\nYour solution (trapping _inside_ the job, too) works for me, btw. Here's\na patch for cg-log that reduces the clutter to two \"Broken pipe\" lines\n(pun not intended).\n\nRene\n\n\n--- cg-log~\t2005-04-29 23:43:09.000000000 +0200\n+++ cg-log\t2005-04-30 12:15:40.000000000 +0200\n@@ -16,6 +16,7 @@\n # or id1:id2 representing an (id1;id2] range of commits to show.\n \n . cg-Xlib\n+trap exit SIGPIPE\n \n if [ \"$1\" = \"-c\" ]; then\n \tshift\n@@ -47,6 +48,7 @@\n fi\n \n $revls | $revsort | while read time commit parents; do\n+\ttrap exit SIGPIPE\n \t[ \"$revfmt\" = \"rev-list\" ] && commit=\"$time\"\n \techo $colheader\"\"commit ${commit%:*} $coldefault;\n \tcat-file commit $commit | \\\n"},{"id":"2291","messageId":"E1DSDER-0000kS-00@gondolin.me.apana.org.au","threadId":"377","inReplyTo":"20050428202739.GE30308@mythryan2.michonline.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2005-05-01T12:07:31Z","receivedAt":"2005-05-01T12:07:31Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"Ryan Anderson wrote:\n> On Thu, Apr 28, 2005 at 12:21:26PM -0700, Linus Torvalds wrote:\n> \n>> Defining \"DONT_REPORT_SIGPIPE\" in config-top.h when building bash gets rid \n>> of it, but I really don't want to rebuild bash just because of this ;)\n> \n> Debian's bash seems to have that set, so it's a bit hard for me to test\n\nThis issue has been around for years. The discussion that led to\nDebian setting this option may be helpful in understanding it:\n\nhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10494\n\nA brief time line:\n\n11 Jun 1997 The issue was reported to Debian.\n20 Nov 1999 Chet Ramey remarks that bash's default will not change.\n 4 Sep 2004 Debian sets DONT_REPORT_SIGPIPE.\n\nChet Ramey claims that setting DONT_REPORT_SIGPIPE by default\nwould make bash incompatible with every other shell out there.\nInterestingly, all the non-bash shells that I've tried disagree\nwith him.\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} \nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"},{"id":"2295","messageId":"4274FB10.6090600@dwheeler.com","threadId":"377","inReplyTo":"E1DSDER-0000kS-00@gondolin.me.apana.org.au","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-05-01T15:51:44Z","receivedAt":"2005-05-01T15:51:44Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Herbert Xu wrote:\n> This issue has been around for years. The discussion that led to\n> Debian setting this option may be helpful in understanding it:\n> \n> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10494\n\nThanks for the pointer. That discussion points\nto some alternative fixes that may be more useful\n(instead of installing a repaired shell).\n\nOne approach is to install a trap for SIGPIPE in\nnon-terminating command in a pipeline where the\nlater items might not process all the data, e.g.:\n (trap {} SIGPIPE; find .) | head -1\n\n\nTHIS IS A REALLY, REALLY BAD DECISION BY THE BASH TEAM.\nWhy should the default be \"create annoying spurious error report?\".\nThis should at least be a run-time settable option,\nwith the OPPOSITE default.\n\n\nWhich is sad, bash is generally reasonably good.\nI guess now I have to say \"bash, once properly configured\nusing DONT_REPORT_SIGPIPE, is reasonably good.\"\n\n\n--- David A. Wheeler\n"},{"id":"2367","messageId":"20050502091027.6753998e.pj@sgi.com","threadId":"377","inReplyTo":"4274FB10.6090600@dwheeler.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-05-02T16:10:27Z","receivedAt":"2005-05-02T16:10:27Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"David wrote:\n> One approach is to install a trap for SIGPIPE in\n> non-terminating command in a pipeline where the\n> later items might not process all the data, e.g.:\n> (trap {} SIGPIPE; find .) | head -1\n\nBoth the versions of bash that I looked at (2.05 and 3.0) _still_\ncomplain even if SIGPIPE is trapped - they just complain with\na more terse message, unless DONT_REPORT_SIGPIPE is not defined.\n\nLinus's version apparently isn't even more terse with this trap.\n\nWhat bash do you have that this trap silences?\n\n> ... rant ...\n\nagreed\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"2406","messageId":"20050502151714.7a33d79d.pj@sgi.com","threadId":"377","inReplyTo":"20050430110410.GA25322@lsrfire.ath.cx","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-05-02T22:17:14Z","receivedAt":"2005-05-02T22:17:14Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Rene wrote:\n> Are you sure it's SMP dependant?\n\nNo - I'm not sure. It just happened to be that way on the couple of\nsystems I looked at (and I figured that in any case, it was a good bet\nthat Linus had multiple processors ;).\n\n> Here's a patch for cg-log\n\nLooks plausible to me.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"2413","messageId":"20050502231743.GL20818@pasky.ji.cz","threadId":"377","inReplyTo":"20050430110410.GA25322@lsrfire.ath.cx","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-02T23:17:43Z","receivedAt":"2005-05-02T23:17:43Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Apr 30, 2005 at 01:04:10PM CEST, I got a letter\nwhere Rene Scharfe told me that...\n> On Fri, Apr 29, 2005 at 11:29:22PM -0700, Paul Jackson wrote:\n> > Linus replied to pj:\n> > > > Code Sample 2:\n> > > > ...\n> > > Didn't change anything for me. Same thing.\n> > \n> > I don't believe you did what I did.\n> > \n> > The source code for bash, both 2.x and 3.x versions, clearly displays a\n> > simpler error message (no line number or redisplay of your script\n> > commands) in the case that you set a trap. And I tested both shells on\n> > a multiprocessor, to verify that they behaved as I expected, running\n> > these silly little scripts.\n> \n> I don't have a multiprocessor and I see the same. Are you sure it's SMP\n> dependant?\n> \n> Your solution (trapping _inside_ the job, too) works for me, btw. Here's\n> a patch for cg-log that reduces the clutter to two \"Broken pipe\" lines\n> (pun not intended).\n\nCould you elaborate on how exactly is it supposed to help? I see\nidentical behaviour with the traps and without them (UP, bash-2.05b).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"2430","messageId":"20050502184424.7cb7f2a4.pj@sgi.com","threadId":"377","inReplyTo":"20050502231743.GL20818@pasky.ji.cz","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-05-03T01:44:24Z","receivedAt":"2005-05-03T01:44:24Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"> Could you elaborate on how exactly is it supposed to help?\n\nThe key code is in bash/jobs.c.\n\nIf you have a bash while or for loop feeding a pipe that shuts down\nwhile the loop is still running commands that try to write the pipe\n(perhaps you were pipe'ing to \"head -1\", and it exit'd, having read its\none line), then the next command to attempt to write that pipe will die,\nand the bash instance that is handling that loop (and forked that\ncommand that just died) will notice the command died with a SIGPIPE\nsignal.\n\nAt this point, one of three possible things happens:\n\n 1) If your bash is compiled with DONT_REPORT_SIGPIPE defined, then\n that bash instance quietly leaves. The concensus around here\n is that is \"good(tm).\"\n\n 2) If not so compiled, then:\n\n\t2a) If you set a trap on SIGPIPE in that shell, it prints:\n\n\t\tfprintf (stderr, \"%s\", j_strsignal (termsig));\n\n\t2b) Else if you did not trap SIGPIPE, it prints:\n\n\t\tfprintf (stderr, \"%s: line %d: \", get_name_for_error (),\n\t\t\t\t(line_number == 0) ? 1 : line_number);\n\t\tpretty_print_job (job, JLIST_NONINTERACTIVE, stderr);\n\n\nThe pretty_print_job() in (2b) can be a multi-line confusion.\n\nSample output for (2a):\n\n\tBroken pipe\n\nSample output in simple one line case for (2b):\n\n\tfoo: line 2: 11663 Broken pipe cat /etc/termcap\n\nA couple of others are reporting different behaviour than what I report\nabove - including Linus.\n\nSo it is almost certain that I don't understand all I know about this.\n\nWhat behaviour do you see?\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"2556","messageId":"427833AE.6030505@dwheeler.com","threadId":"377","inReplyTo":"20050502091027.6753998e.pj@sgi.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-05-04T02:30:06Z","receivedAt":"2005-05-04T02:30:06Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"I reported:\n>>One approach is to install a trap for SIGPIPE in\n>>non-terminating command in a pipeline where the\n>>later items might not process all the data, e.g.:\n>> (trap {} SIGPIPE; find .) | head -1\n\nPaul Jackson wrote:\n> Both the versions of bash that I looked at (2.05 and 3.0) _still_\n> complain even if SIGPIPE is trapped - they just complain with\n> a more terse message, unless DONT_REPORT_SIGPIPE is not defined.\n...\n> What bash do you have that this trap silences?\n\nActually, I have a working bash, so I can't test any of\nthese work-arounds. I was merely foolish enough to quote\nthe Debian discussion, where someone reported that as a\nwork-around. I had hopes that it would help.\nThat'll teach me to pay attention to documentation :-).\n\nI wonder, does a top-level trap work? E.g.:\n trap \"\" SIGPIPE\n ...\n\nAnyone, good luck to those with broken bashes...\n\n--- David A. Wheeler\n"},{"id":"2557","messageId":"Pine.LNX.4.58.0505031947530.26698@ppc970.osdl.org","threadId":"377","inReplyTo":"427833AE.6030505@dwheeler.com","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-04T02:50:07Z","receivedAt":"2005-05-04T02:50:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 May 2005, David A. Wheeler wrote:\n> \n> I wonder, does a top-level trap work? E.g.:\n> trap \"\" SIGPIPE\n\nNo.\n\nBut putting the traps _inside_ the loops seems to help. So something like \nthe appended at least makes it somewhat useful\n\nAnd yes, you need them at both levels, it appears. Or maybe that just \nchanges the timing enough. Whatever.\n\n\t\t\tLinus\n----\nIndex: cg-log\n===================================================================\n--- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-log (mode:100755 sha1:aa2abf370753117a350818dbc91991b14d30ec6b)\n+++ uncommitted/cg-log (mode:100755)\n@@ -47,10 +47,12 @@\n fi\n \n $revls | $revsort | while read time commit parents; do\n+\ttrap \"exit 1\" SIGPIPE\n \t[ \"$revfmt\" = \"git-rev-list\" ] && commit=\"$time\"\n \techo $colheader\"\"commit ${commit%:*} $coldefault;\n \tgit-cat-file commit $commit | \\\n \t\twhile read key rest; do\n+\t\t\ttrap \"exit 1\" SIGPIPE\n \t\t\tcase \"$key\" in\n \t\t\t\"author\"|\"committer\")\n \t\t\t\tif [ \"$key\" = \"author\" ]; then\n"},{"id":"2564","messageId":"E1DTFD7-00063T-00@gondolin.me.apana.org.au","threadId":"377","inReplyTo":"Pine.LNX.4.58.0505031947530.26698@ppc970.osdl.org","subject":"Re: How to get bash to shut up about SIGPIPE?","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2005-05-04T08:26:25Z","receivedAt":"2005-05-04T08:26:25Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"Linus Torvalds wrote:\n> \n> But putting the traps _inside_ the loops seems to help. So something like \n> the appended at least makes it somewhat useful\n\nIt's not the loop that's important, but the subshell where the\nsignal is caught. Every time you enter a subshell all traps are\nreset. Since anything that comes (before or) after a pipe symbol\ngoes into a subshell...\n\n> Index: cg-log\n> ===================================================================\n> --- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-log (mode:100755 sha1:aa2abf370753117a350818dbc91991b14d30ec6b)\n> +++ uncommitted/cg-log (mode:100755)\n> @@ -47,10 +47,12 @@\n> fi\n> \n> $revls | $revsort | while read time commit parents; do\n> + trap \"exit 1\" SIGPIPE\n> [ \"$revfmt\" = \"git-rev-list\" ] && commit=\"$time\"\n> echo $colheader\"\"commit ${commit%:*} $coldefault;\n> git-cat-file commit $commit | \\\n> while read key rest; do\n> + trap \"exit 1\" SIGPIPE\n> case \"$key\" in\n> \"author\"|\"committer\")\n> if [ \"$key\" = \"author\" ]; then\n\nYou need it in both places because the signal may be received\nin either place, depending on whether it's the echo or something\ninside the loop that dies while writing output.\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} \nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"}]}