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

Previous Next

Full log

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

From: Jim Meyering <jim <at> meyering.net>
To: bug-grep <at> gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24941 <at> debbugs.gnu.org
Subject: Re: bug#24941: Early termination bug in grep 2.26
Date: Mon, 14 Nov 2016 07:31:36 -0800

On Sun, Nov 13, 2016 at 5:56 PM, Gary Johnson <garyjohn <at> spocom.com> wrote:
> There was some recent discussion on the vim_dev list of a failure to
> update a Vim package which was found to be due to an update of grep
> from 2.25 to 2.26.  The details of the grep behavior are discussed
> here:
>
> https://www.linuxquestions.org/questions/slackware-14/pkgtools-grep-bug-in-slackware[64]-current-4175593054/
>
> In short, it seems to be due to the "grep: /dev/null output
> speedup" commit of 2016-05-01, af6af288eac28951b5eee1eaaf373e22b2193b7b.
> When grep terminates early, it closes the pipe it's reading stdin
> from, which terminates the program on the other side of that pipe
> early, before that program has completed its task.
>
> Oops.

Thank you for the report.

Oops, indeed.

While I  see nothing in the POSIX specification
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html)
that requires it to read all input in such a case, I think the current
behavior violates least-surprise.

Here is an example to demonstrate. I believe that POSIX does not
dictate what this code prints:

grep-2.25:

  $ (seq 10000000; echo $? 1>&2) | grep . > /dev/null
  0

grep-2.26:

  $ (seq 10000000; echo $? 1>&2) | grep . > /dev/null
  141

Paul, what do you think about making your heuristic apply only for non-pipes?

Previous Next

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