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: Jim Meyering <jim <at> meyering.net>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#20974: closed (Weird newline matching behaviour in
 --null-data mode)
Date: Sat, 04 Jul 2015 03:11:02 +0000

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

Your message dated Fri, 3 Jul 2015 20:10:08 -0700
with message-id <CA+8g5KHRHJtnQ-D5DKo09RRN1_vQACiFwp8Xx_GL-BkOi5D9qQ <at> mail.gmail.com>
and subject line Re: bug#20974: Weird newline matching behaviour in --null-data mode
has caused the debbugs.gnu.org bug report #20974,
regarding Weird newline matching behaviour in --null-data mode
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: 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

[Message part 3 (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.

Previous Next

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