Your message dated Tue, 15 Jan 2019 15:07:10 +0100
with message-id <20190115140630.GH3252@novelo>
and subject line Re: grep: Misleading error message when presenting a badly
formed character class
has caused the Debian Bug report #525213,
regarding grep: Misleading error message when presenting a badly formed
character class
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
525213: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525213
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: grep
Version: 2.5.4-4
Severity: normal
It seems that whenever egrep finds something it cannot digest inside a
character class, it spews out the same error string: «Unmatched [ or [^».
This can be misleading and opens the way for long debugging time,
specially when trying to understand complex regexes. To illustrate the
point:
$ echo | egrep -v '[[:digit]]+'
egrep: Unmatched [ or [^
The brackets _are_ balanced, however the character class is not (it
lacks a finishing colon).
Thanks,
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-vserver-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grep depends on:
ii libc6 2.9-7 GNU C Library: Shared libraries
grep recommends no packages.
Versions of packages grep suggests:
ii libpcre3 7.8-2 Perl 5 Compatible Regular Expressi
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 3.1-3
El 31/12/18 a las 12:46, Aurelien Jarno escribió:
> Version: 2.28-0experimental0
>
> On 2016-02-29 19:47, [email protected] wrote:
> > control: clone -1 -2
> > control: retitle -2 "regex: fix [ diagnostic"
> > control: reassign -2 glibc
> > control: tags -2 + patch
> > control: block -1 -2
> >
> > El 26/02/16 a las 08:49, Jim Meyering escribió:
> > > On Fri, Feb 26, 2016 at 6:51 AM, <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > I'd like to forward a bug filled by Gunnar Wolf in Debian some time
> > > > ago:
> > > >
> > > > "It seems that whenever egrep finds something it cannot digest inside a
> > > > character class, it spews out the same error string: «Unmatched [ or
> > > > [^».
> > > > This can be misleading and opens the way for long debugging time,
> > > > specially when trying to understand complex regexes. To illustrate the
> > > > point:
> > > >
> > > > $ echo | egrep -v '[[:digit]]+'
> > > > egrep: Unmatched [ or [^
> > > >
> > > > The brackets _are_ balanced, however the character class is not (it
> > > > lacks a finishing colon)."
> > >
> > > Thank you for forwarding that.
> > > The diagnostic was fixed in gnulib via a commit last month:
> > > git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c6e85cf4eccbd5129
>
> This change went into glibc when it has been synced with gnulib in
> commit eb04c21373e, which is included in glibc 2.28. I am therefore
> closing this bug with this version.
And then, this bug can be closed in grep. 3.1-3 was the first version
that build on glibc 2.28.
cheers,
Santiago
signature.asc
Description: PGP signature
--- End Message ---
