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".