GNU bug report logs - #24941
Early termination bug in grep 2.26

Previous Next

Package: grep;

Reported by: Gary Johnson <garyjohn <at> spocom.com>

Date: Mon, 14 Nov 2016 02:42:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jim <at> meyering.net, 24941 <at> debbugs.gnu.org
Cc: garyjohn <at> spocom.com
Subject: bug#24941: Early termination bug in grep 2.26
Date: Tue, 15 Nov 2016 00:17:03 -0800
Jim Meyering wrote:
> Paul, what do you think about making your heuristic apply only for non-pipes?

I'm a bit dubious, as grep exits early for other reasons, and did so before the 
patch in question. For example, here:

seq 10000000000 | grep -q .

This is as of grep 2.19 (2014), due to a bug report where grep performed badly 
by not exiting early <https://bugs.gnu.org/17427>. Which suggests that we'll get 
bug reports in this area no matter what grep does....

Looking at other implementations, Solaris 11 grep is similar with -q. And 
FreeBSD-current grep exits early for this case:

seq 10000000000 | grep -f /dev/null

Come to think of it, perhaps GNU grep should do a similar optimization for -f 
/dev/null, if only to keep up with FreeBSD.

All the above being said, I am sympathetic to the bug report. Perhaps we can 
eliminate the optimization if there are no file arguments and only options in 
the set -EFivx are specified. Something like that anyway. The idea is to catch 
common cases in old (and really, broken) scripts, without hurting performance in 
general.




This bug report was last modified 8 years and 277 days ago.

Previous Next


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