bug#25048: --with-included-regex vs. e-acute piped into LC_ALL=fr_FR.iso88591 grep '[d-f]'

[Jim Meyering]

When grep is configured --with-included-regex, the following command
fails to print the expected match:

   printf '\351\n' |LC_ALL=fr_FR.iso88591 src/grep '[d-f]'

You wouldn't notice on glibc-based systems, since the default there is
to use the glibc-supplied regex code, which does make grep detect the
match.

However, on other systems (I noticed on OS X), configuration machinery
detects that we have to resort to the included regex matcher, and
there, the default build results in a grep binary that fails the new
unibyte-bracket-expr test.

Why? Because the included regcomp.c has two code paths: one for #if
_LIBC (that is collating-sequence aware), and the other that ignores
collation sequences. The former can be used only when building glibc
itself, and is the path we require in order to handle this case.  The
latter code is what we get when compiling any place else.

Since it's always been this way, I don't plan to attempt a work-around
before the next release, and instead will probably arrange for that
test to be skipped when grep is built with the included regex.

Other ideas welcome,

Jim