Ævar Arnfjörð Bjarmason wrote: > The failure is totally predicated on whether or not REG_STARTEND is > available on the system [...] > Then you could do: > > test_expect_success REG_STARTEND 'git grep ile a' ' > git grep ile a > ' Sorry to harp on this, but no, that would not be right. When REG_STARTEND is not available on a system, this is still a bug and we still want to know when it is fixed. The test should not be skipped. So one could do: if have_reg_startend then expectation=success else expectation=failure fi test_expect_$expectation 'git grep ile a' ' git grep ile a ' > The glibc one is probably pretty good as far as minimal POSIX DFA > engines go. Hopefully you can patch it up to get it to compile on > non-GNU systems. No promises, in particular because I don’t have any non-GNU installations handy to test on. Probably gnulib’s copy will do, as Andreas suggested. > Regarding regular expression implementations. We might want to look > into bundling one implementation and using it everywhere Please no. :) If we can do better than glibc, then glibc should be improved (yes, I know GNU grep does much better than glibc already). > Using NFA engines like that also gives you some performance guarantees Do you mean “using DFA engines”? i.e. I thought GNU grep avoids backtracking by converting the NFA to a DFA, at least conceptually. Thanks for the food for thought, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html