GNU bug report logs - #23267
suggestion: silently ignore EPIPE errors when SIGPIPE is set to 'ignore'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23267 in the body.
You can then email your comments to 23267 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: suggestion: silently ignore EPIPE errors when SIGPIPE is set to
 'ignore'
Date: Mon, 11 Apr 2016 02:36:26 -0400

[Message part 1 (text/plain, inline)]

Hello,

This is a small addition to a recent change:
   1cec27a7f0e5c7bdc44a88ef51af09f87a8cbc24 
   grep: use errno consistently in write diagnostics

With the above change, if SIGPIPE is set to 'ignore' (e.g. by the shell or python),
then grep would exit with "write error: Broken Pipe".
Based on recent suggestion from Pádraig Brady
( http://lists.gnu.org/archive/html/coreutils/2016-04/msg00004.html ) perhaps it would be better
to have special case for EPIPE and exit silently (as if SIGPIPE was not ignored and terminated the program?).

Patch attached for such modification.

One issue of which I'm not certain: I assumed that if 'prline' was called, a match was found.
Thus, EPIPE will result in exit(EXIT_SUCCESS) indicating a match.


Comments welcomed,
 - Assaf

[0001-grep-silently-ignore-EPIPE-errors.patch (application/octet-stream, attachment)]

Message #8 received at 23267 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>, 23267 <at> debbugs.gnu.org
Subject: Re: bug#23267: suggestion: silently ignore EPIPE errors when SIGPIPE
 is set to 'ignore'
Date: Mon, 11 Apr 2016 00:47:13 -0700

Assaf Gordon wrote:
> With the above change, if SIGPIPE is set to 'ignore' (e.g. by the shell or python),
> then grep would exit with "write error: Broken Pipe".
> Based on recent suggestion from Pádraig Brady

I don't see why this is would be a good idea. grep should report write errors.

A caller that doesn't care about EPIPE output errors should invoke 'grep' with 
the default behavior for SIGPIPE and should ignore grep's exit status; this is 
longstanding tradition. As far as I can see, it's a mistake to ignore SIGPIPE 
while expecting a status of zero with no output-error diagnostics. Such a 
mistake would affect lots of programs other than 'grep', and it's not incumbent 
on utility writers to work around mistakes like this.

Message #11 received at 23267 <at> debbugs.gnu.org (full text, mbox):

From: Fredrik Fornwall <fredrik <at> fornwall.net>
To: 23267 <at> debbugs.gnu.org
Subject: Re: bug#23267: suggestion: silently ignore EPIPE errors when SIGPIPE
 is set to 'ignore'
Date: Sat, 23 Apr 2016 13:13:44 +0200

Even when SIGPIPE has the default behaviour, it seems that there is a
timing issue if grep has the time to treat EPIPE as an error before
the process being killed due to the delivery of the signal.

This seems to happen easily when running on Android (perhaps due to
slower signal delivery, or relatively faster output, or how it runs on
a multi-cpu setup), as seen from the below run:

$ seq 9999 |grep -v xxx |head -1
1
grep: write error: Broken pipe

This would motivate silently ignoring EPIPE to avoid having different
behaviour depending on timing issues. See also
http://superuser.com/questions/554855/how-can-i-fix-a-broken-pipe-error.

Message #20 received at 23267-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 23267-done <at> debbugs.gnu.org
Subject: Re: bug#23267: suggestion: silently ignore EPIPE errors when SIGPIPE
 is set to 'ignore'
Date: Tue, 22 Sep 2020 15:35:32 -0700

I'm cleaning up old grep bug reports and am closing this one as wontfix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.