GNU bug report logs - #20974
Weird newline matching behaviour in --null-data mode

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Balazs Kezes <rlblaster <at> gmail.com>
Subject: bug#20974: closed (Re: bug#20974: Weird newline matching
 behaviour in --null-data mode)
Date: Sat, 04 Jul 2015 03:11:03 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#20974: Weird newline matching behaviour in --null-data mode

which was filed against the grep package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 20974 <at> debbugs.gnu.org.

-- 
20974: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20974
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Meyering <jim <at> meyering.net>
To: Balazs Kezes <rlblaster <at> gmail.com>
Cc: 20974-done <at> debbugs.gnu.org
Subject: Re: bug#20974: Weird newline matching behaviour in --null-data mode
Date: Fri, 3 Jul 2015 20:10:08 -0700

On Fri, Jul 3, 2015 at 8:03 PM, Jim Meyering <jim <at> meyering.net> wrote:
> On Fri, Jul 3, 2015 at 9:59 AM, Balazs Kezes <rlblaster <at> gmail.com> wrote:
>> Hello!
>>
>> I'm running into issues with grep in -z mode. I've managed to minimize
>> it into this:
>>
>>         $ seq 2 | grep --null-data --quiet '[12].2' ; echo $?
>>         0
>>         $ seq 2 | grep --null-data --quiet '[1-2].2' ; echo $?
>>         1
>
> Thank you for the report.
> I too would like those two commands to work the same way.
> The problem is that when the regular expression contains a
> bracket expression with a range, grep switches from using
> its DFA matcher to relying on regex, but as Norihiro Tanaka
> mentioned, grep's use of the regex matcher with the
> --null-data (-z) option cannot match multi-line results.
>
> One can demonstrate the problem in the C locale too,
> by using a back-reference, since that construct also causes
> grep to use regex:
>
>   $ printf '1\n1\n' |LC_ALL=en_US.UTF-8 src/grep -Ezq '1.1'
>   $ printf '1\n1\n' |LC_ALL=en_US.UTF-8 src/grep -Ezq '(1).\1'
>   [Exit 1]
>   $ printf '1\n1\n' |LC_ALL=C src/grep -Ezq '(1).\1'
>   [Exit 1]
>
> It'd be great to fix this, but it is not on my short-term radar,
> though I will add some expected-to-fail tests.

Oh, nice! I see that Paul Eggert has just fixed this with
the following patch:
  http://git.sv.gnu.org/cgit/grep.git/commit/?id=0e8fda0d880cccd0

So I'm closing this ticket.

[Message part 3 (message/rfc822, inline)]

From: Balazs Kezes <rlblaster <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: Weird newline matching behaviour in --null-data mode
Date: Fri, 3 Jul 2015 17:59:19 +0100

Hello!

I'm running into issues with grep in -z mode. I've managed to minimize
it into this:

	$ seq 2 | grep --null-data --quiet '[12].2' ; echo $?
	0
	$ seq 2 | grep --null-data --quiet '[1-2].2' ; echo $?
	1

I'd expect the two expressions to mean the same. I've tried this with
the latest version built from the official sources, 2.21. I've also
found [1] which might be related but it wasn't updated for almost 2
years. Or is this expected?

Thanks!


[1] http://savannah.gnu.org/bugs/?40009

-- 
Balazs

Previous Next

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