t7810.94 (git-grep -E -F -G) never passed

I'm not sure why it's supposed to pass, actually.  -G makes the pattern be a basic regex and basic regexen don't recognize the + repetition operator.

expecting success: 
	echo ab:aab >expected &&
	git grep -E -F -G a\\+b >actual &&
	test_cmp expected actual

--- expected 2011-05-25 03:19:05.000000000 +0000 +++ actual 2011-05-25 03:19:05.000000000 +0000

Brian Gernhardt venit, vidit, dixit 25.05.2011 05:27:

"Never" is a strong statement when this test always passed for everyone else running tests, assuming they would have reported otherwise. What's your system?

reg-ex.info says:

"The other BRE metacharacters require a backslash to give them their special meaning."

"Some implementations support \? and \+... but \? and \+ are not part of the POSIX standard."

So I guess we're going with "some".

Michael

On May 25, 2011, at 6:21 AM, Michael J Gruber wrote:

My apologies.  It was late and I wasn't explicit enough.  What I meant was:

"This test has failed on my system ever since the commit that introduced it."

My system is running OS X 10.6.7.

Some would be right.  I tend to find that the BSD (and BSD-like) libraries on OS X are more strict and have less features than the GNU equivalents.  (The fact that OS X's libreadline is actually the only mostly compatible libedit drives me batty sometimes.)

This does leave us with the question of what to do with the test.  Perhaps a pattern like "a*+b" to match "aa+b"?  Plain + should always match just + in a BRE, even if \+ is special, and the * makes sure that it is a regex instead of plain string matching.

~~ Brian

Brian Gernhardt <brian <at> gernhardtsoftware.com> writes:

OS X are more strict and have less

actually the only mostly

pattern like "a*+b" to match

and the * makes sure that it is a

You're right about \+ in BRE. I guess I missed that because glibc's implementation isn't strict BRE. I'll post a patch that fixes this problem. Thanks for catching this up!