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 100 | grep -q .
This is as of grep 2.19 (2014), due to a bug re
On Tue, Nov 15, 2016 at 12:17 AM, Paul Eggert wrote:
> 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 1000
On Tue, 15 Nov 2016 11:35:15 -0800
Jim Meyering wrote:
> I suppose you mean in addition to the S_ISFIFO test? That sounds good.
> We should retain the optimization when reading from stdin that is a
> non-pipe.
This can also happen in stdin. If we redirect stdout to /dev/null,
grep-2.26 exits i
On Tue, Nov 15, 2016 at 2:13 PM, Norihiro Tanaka wrote:
>
> On Tue, 15 Nov 2016 11:35:15 -0800
> Jim Meyering wrote:
>
>> I suppose you mean in addition to the S_ISFIFO test? That sounds good.
>> We should retain the optimization when reading from stdin that is a
>> non-pipe.
>
> This can also ha
On 11/15/2016 03:13 PM, Jim Meyering wrote:
We should retain the optimization when reading from stdin that is
neither a pipe nor a tty.
I am toying with the idea of retaining the optimization only if
lseek-to-EOF succeeds, a heuristic that is a bit more restrictive. This
arguably would con
On Tue, Nov 15, 2016 at 3:33 PM, Paul Eggert wrote:
> On 11/15/2016 03:13 PM, Jim Meyering wrote:
>>
>>We should retain the optimization when reading from stdin that is
>> neither a pipe nor a tty.
>
> I am toying with the idea of retaining the optimization only if lseek-to-EOF
> succeeds, a h
