GNU bug report logs - #28105
Inconsistent exit code with --files-without-match

Previous Next

Full log

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

From: Antonio Diaz Diaz <antonio <at> gnu.org>
To: bug-grep <at> gnu.org
Subject: bug#28105: Inconsistent exit code with --files-without-match
Date: Fri, 07 Aug 2020 13:14:05 +0200

Sorry for being late in the conversation, but I didn't know about this 
change in grep's exit status until now.

On Tue, 15 Aug 2017 22:16:58 -0700 Paul Eggert wrote:
> The grep documentation says exit status depends on whether lines (not
> files) are selected, so grep is conforming to its documentation here.

Conforming to its documentation and to POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
EXIT STATUS
    The following exit values shall be returned:
     0  One or more lines were selected.
     1  No lines were selected.
    >1  An error occurred.

Inverting the exit status of 'grep -L' also departs from the exit status one 
could expect from the etymology of grep itself. (The ed command 'g/RE/p' 
fails if no lines match).


> Perhaps grep's documentation and behavior could be changed, though I
> worry that existing uses of grep might be adversely affected.

I have recently received a report[1] that the change[2] in exit status of 
GNU grep when using -L has in fact affected zgrep adversely.
[1] http://www.mail-archive.com/zutils-bug <at> nongnu.org/msg00120.html
[2] http://www.mail-archive.com/bug-grep <at> gnu.org/msg06886.html

This change in grep breaks zgrep (from zutils) and gzgrep (from gzip) (and 
possibly other *zgrep tools) because they both feed the decompressed 
contents of the file to grep through stdin and must replace the string 
"(standard input)" printed by grep with the name of the matching file, for 
which they depend on the exit status of grep which has now been changed.

What worries me most is that I have been unable to find a reliable way to 
make zgrep work with both old and new versions of GNU grep.

This change may also be incompatible with other tools like grep-dctrl:
http://manpages.debian.org/stretch/dctrl-tools/grep-dctrl.1.en.html#DIAGNOSTICS

This change also breaks the internal logic of the -q option. Until GNU grep 
3.1 the -q (quiet) option just suppressed the output, but didn't change the 
exit status in absence of errors. But in GNU grep 3.2 to 3.4 -q inverts the 
exit status when -L is also used. Now 'grep -L > /dev/null' and 'grep -Lq' 
return opposite values.

Note that the original reporter who requested this change in GNU grep also 
reported the inconsistency of -Lq to git-grep:
http://marc.info/?l=git&m=150281283027760&w=2
Inconsistent exit code for `git grep --files-without-match` with `--quiet`
  $ ./git-grep --files-without-match nope -- blob.c; echo $?
  blob.c
  0
  $ ./git-grep --files-without-match --quiet nope -- blob.c; echo $?
  1
  I expect both to exit 0

I propose to revert this change to remain consistent with POSIX. If this is 
not possible or desirable, then I propose to limit the function of -q to 
quieten standard output but without reversing the exit status of -L, and 
modify the POSIX standard to reflect this change.

Best regards,
Antonio.

Previous Next

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