On Mon, Jan 09, 2017 at 02:05:44PM +0100, Andreas Schwab wrote: > On Jan 09 2017, "A. Wilcox" <awilfox@xxxxxxxxxxxxxxx> wrote: > > > Interestingly enough, you seem to be right. The failure is very > > bizarre and has nothing to do with system /bin/grep: > > > > test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab > > not ok 142 - grep -G -F -P -E pattern > > # > > # >empty && > > # test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c" > > ab >actual && > > # test_cmp empty actual > > # > > > > However: > > > > elaine trash directory.t7810-grep # git grep -G -F -P -E > > a\x{2b}b\x{2a}c ab >actual > > You need to quote the regexp argument, see the line starting with > "test_must_fail" above. Oh, duh. I checked that the line in the test was quoted, and didn't notice that only the unquoted version he ran later complained. Thanks for noticing, as that explains the mystery, I think. The problem is that we are expecting the regex "\x{2b}" to complain in regcomp() (as an ERE), but it doesn't. And that probably _is_ related to musl, which is providing the libc regex (I know this looks like a pcre test, but it's checking that "-P -E" overrides the pcre option with "-E"). I'm not sure if musl is wrong for failing to complain about a bogus regex. Generally making something that would break into something that works is an OK way to extend the standard. So our test is at fault for assuming that the regex will fail. I guess we'd need to find some more exotic syntax that pcre supports, but that ERE doesn't. Maybe "(?:)" or something. -Peff