gnu/167009: grep(1): GNU grep -q can exit !0 even if strings found

[Jilles Tjoelker]

The following reply was made to PR gnu/167009; it has been noted by GNATS.

From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, david at catwhisker.org
Cc:  
Subject: Re: gnu/167009: grep(1): GNU grep -q can exit !0 even if strings
 found
Date: Tue, 17 Apr 2012 21:08:12 +0200

 FreeBSD PR gnu/167009:
 > [strings -a /usr/local/bin/bison | grep -qw /usr/local fails]
 
 The peculiar thing is the shell, tcsh.
 
 What happens is that grep -q terminates early, so that strings receives
 SIGPIPE when it tries to write further data. Whereas the exit status
 of a pipeline in sh is always the exit status of the last element so
 that your command has the expected behaviour, this is different in tcsh.
 Tcsh looks backwards for a failing command if the last element has exit
 status 0, and returns the 141 corresponding to SIGPIPE.
 
 If you do not use -q, grep reads all of its input and strings will not
 be hit by SIGPIPE, so the exit status of the pipeline is the exit status
 of grep.
 
 Something similar happens if 'set -o pipefail' is in effect in bash or
 ksh93.
 
 I can't help but be happy that I'm not using tcsh, because
   tcsh -c 'yes | :'
 does return 0 (apparently it doesn't look backwards if the last element
 is a builtin) and
   tcsh -c 'yes | if (1) true'
 hangs. Also, the double prompt I see after typing
   yes | :
 in an interactive tcsh doesn't really inspire confidence.
 
 -- 
 Jilles Tjoelker