gnu/167009: grep(1): GNU grep -q can exit !0 even if strings
jilles at stack.nl
Tue Apr 17 19:10:06 UTC 2012
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
Subject: Re: gnu/167009: grep(1): GNU grep -q can exit !0 even if strings
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
Something similar happens if 'set -o pipefail' is in effect in bash or
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.
More information about the freebsd-bugs