bug#24941: Early termination bug in grep 2.26

[Jim Meyering]

On Sun, Nov 13, 2016 at 5:56 PM, Gary Johnson <address@hidden> 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?