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, <santiag...@riseup.net> 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 > Thus, as long as grep is configured --with-included-regex, > you will now see this: > > $ grep -E '[[:digit]]+' > grep: Unmatched [, [^, [:, [., or [= > > If grep is configure with --without-included-regex, you will > still see the inferior diagnostic, but that string will then be > coming from your system's C library. > > Since fixing glibc's copy of regcomp.c is outside the scope > of grep's issue tracker, I'm marking this as "done". Thanks for you answer, Jim. I'm then filling a bug against Debian's glibc. Cheers, Santiago
