GNU bug report logs - #78940
REGEX wrongfully matches pattern

Previous Next

Package: sed;

Reported by: "Duchesne, Alexandre" <duchesne.alexandre.3 <at> courrier.uqam.ca>

Date: Wed, 2 Jul 2025 05:43:03 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

To reply to this bug, email your comments to 78940 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-sed <at> gnu.org:
bug#78940; Package sed. (Wed, 02 Jul 2025 05:43:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Duchesne, Alexandre" <duchesne.alexandre.3 <at> courrier.uqam.ca>:
New bug report received and forwarded. Copy sent to bug-sed <at> gnu.org. (Wed, 02 Jul 2025 05:43:04 GMT) Full text and rfc822 format available.

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

From: "Duchesne, Alexandre" <duchesne.alexandre.3 <at> courrier.uqam.ca>
To: "bug-sed <at> gnu.org" <bug-sed <at> gnu.org>
Subject: REGEX wrongfully matches pattern 
Date: Tue, 1 Jul 2025 20:26:16 +0000
[Message part 1 (text/plain, inline)]
Hi,

I wanted to show to my classmate the comportment of a RegEX using sed to capture the subgroup in a pattern match.

But, when trying with sed -E, the pattern matched even though it should not have.

Can someone explain to me why if this comportment turns out to be normal ?

View snippet :

$ echo abc | grep -E '(...).+' -c
0
$ echo abc | sed -E 's/(...).+/\1/'
abc
$ sed --version
sed (GNU sed) 4.9
Packaged by Debian
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Jay Fenlason, Tom Lord, Ken Pizzini,
Paolo Bonzini, Jim Meyering, and Assaf Gordon.

This sed program was built with SELinux support.
SELinux is disabled on this system.

GNU sed home page: <https://www.gnu.org/software/sed/>.
General help using GNU software: <https://www.gnu.org/gethelp/>.
E-mail bug reports to: <bug-sed <at> gnu.org>.


Regards,

-Alexandre.


[Message part 2 (text/html, inline)]

Information forwarded to bug-sed <at> gnu.org:
bug#78940; Package sed. (Wed, 02 Jul 2025 13:27:04 GMT) Full text and rfc822 format available.

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

From: Davide Brini <dave_br <at> gmx.com>
To: 78940 <at> debbugs.gnu.org
Subject: Re: bug#78940: REGEX wrongfully matches pattern
Date: Wed, 2 Jul 2025 15:26:19 +0200
On Tue, 1 Jul 2025 20:26:16 +0000, "Duchesne, Alexandre"
<duchesne.alexandre.3 <at> courrier.uqam.ca> wrote:

> Hi,
> 
> I wanted to show to my classmate the comportment of a RegEX using sed to
> capture the subgroup in a pattern match.
> 
> But, when trying with sed -E, the pattern matched even though it should
> not have.
> 
> Can someone explain to me why if this comportment turns out to be normal ?
> 
> View snippet :
> 
> $ echo abc | grep -E '(...).+' -c
> 0
> $ echo abc | sed -E 's/(...).+/\1/'
> abc

This is all expected behavior. Your regexp does not match, no sostitution
is performed, and sed prints the input line unchanged, which is the default
behavior (disable with sed -n).

-- 
D.




Reply sent to Jim Meyering <jim <at> meyering.net>:
You have taken responsibility. (Thu, 03 Jul 2025 17:05:03 GMT) Full text and rfc822 format available.

Notification sent to "Duchesne, Alexandre" <duchesne.alexandre.3 <at> courrier.uqam.ca>:
bug acknowledged by developer. (Thu, 03 Jul 2025 17:05:04 GMT) Full text and rfc822 format available.

Message #13 received at 78940-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Davide Brini <dave_br <at> gmx.com>
Cc: 78940-done <at> debbugs.gnu.org
Subject: Re: bug#78940: REGEX wrongfully matches pattern
Date: Thu, 3 Jul 2025 10:03:54 -0700
tags 78940 notabug
close 78940
stop

On Wed, Jul 2, 2025 at 6:27 AM Davide Brini via <bug-sed <at> gnu.org> wrote:
> On Tue, 1 Jul 2025 20:26:16 +0000, "Duchesne, Alexandre"
> <duchesne.alexandre.3 <at> courrier.uqam.ca> wrote:
>
> > Hi,
> >
> > I wanted to show to my classmate the comportment of a RegEX using sed to
> > capture the subgroup in a pattern match.
> >
> > But, when trying with sed -E, the pattern matched even though it should
> > not have.
> >
> > Can someone explain to me why if this comportment turns out to be normal ?
> >
> > View snippet :
> >
> > $ echo abc | grep -E '(...).+' -c
> > 0
> > $ echo abc | sed -E 's/(...).+/\1/'
> > abc
>
> This is all expected behavior. Your regexp does not match, no sostitution
> is performed, and sed prints the input line unchanged, which is the default
> behavior (disable with sed -n).

Thanks for replying. I've marked this issue as resolved and "not a bug".




This bug report was last modified 1 day ago.

Previous Next


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