GNU bug report logs - #51235
resolve old FIXME in PCRE implementation to allow more than 1 expression

Previous Next

To reply to this bug, email your comments to 51235 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Carlo Arenas <carenas <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: resolve old FIXME in PCRE implementation to allow more than 1
 expression
Date: Sat, 16 Oct 2021 00:00:12 -0700

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

With this patch, multiple expressions (from -e or -f) are now
acceptable with -P for easier side by side comparison with the other
supported engines.

Alternatively, multiple expressions could be compiled and run
sequentially for matching, but I suspect the added compilation time is
likely higher, and JIT might be able to run the alteration fast enough
for most cases.

Hopefully this tiny change is better than the status quo, though.

Carlo

[0001-pcre-allow-more-than-1-regular-expression.patch (application/octet-stream, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Carlo Arenas <carenas <at> gmail.com>
Cc: 51235 <at> debbugs.gnu.org
Subject: Re: bug#51235: resolve old FIXME in PCRE implementation to allow more
 than 1 expression
Date: Sat, 16 Oct 2021 00:50:04 -0700

On 10/16/21 12:00 AM, Carlo Arenas wrote:
> With this patch, multiple expressions (from -e or -f) are now
> acceptable with -P for easier side by side comparison with the other
> supported engines.

Surely this mishandles shell commands like this one:

grep -P '[
a]'

which should be an error, but with that patch would not be an error.

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

From: Carlo Arenas <carenas <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 51235 <at> debbugs.gnu.org
Subject: Re: bug#51235: resolve old FIXME in PCRE implementation to allow more
 than 1 expression
Date: Sat, 16 Oct 2021 01:58:29 -0700

On Sat, Oct 16, 2021 at 12:50 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 10/16/21 12:00 AM, Carlo Arenas wrote:
> > With this patch, multiple expressions (from -e or -f) are now
> > acceptable with -P for easier side by side comparison with the other
> > supported engines.
>
> Surely this mishandles shell commands like this one:
>
> grep -P '[
> a]'
>
> which should be an error, but with that patch would not be an error.

of course, but ironically without the patch, the error isn't correct either:

$ grep -P '[
> a]'
grep: the -P option only supports a single pattern

I would say that for a 4 line patch with negative byte count, it is
worth the trade.
But if you feel so strongly against it, doing the one that compiles
every line independently and that will catch that problem wouldn't be
that difficult, but I would rather do it as a follow up, and is
definitely going to be bigger.

Carlo

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Carlo Arenas <carenas <at> gmail.com>
Cc: 51235 <at> debbugs.gnu.org
Subject: Re: bug#51235: resolve old FIXME in PCRE implementation to allow more
 than 1 expression
Date: Sat, 16 Oct 2021 09:46:37 -0700

On 10/16/21 1:58 AM, Carlo Arenas wrote:
> without the patch, the error isn't correct either:
> 
> $ grep -P '[
>> a]'
> grep: the -P option only supports a single pattern

I don't offhand see what's wrong with the diagnostic, as the PATTERNS 
operand is documented to be one that "contains one or more patterns 
separated by newlines".


> doing the one that compiles
> every line independently and that will catch that problem wouldn't be
> that difficult, but I would rather do it as a follow up, and is
> definitely going to be bigger.

Yes, that sounds better. Please keep the followup in this thread. Also, 
I hope you'd be willing to assign copyright to the FSF as I assume these 
changes will be nontrivial. I will send you paperwork info about that 
via separate mail offlist.

Previous Next

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