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

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

[Brian Gernhardt]

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
@@ -1 +1 @@
-ab:aab
+ab:a+b
not ok - 94 grep -E -F -G pattern

~~ Brian G

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

[Michael J Gruber]

Brian Gernhardt venit, vidit, dixit 25.05.2011 05:27:
> 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
> @@ -1 +1 @@
> -ab:aab
> +ab:a+b
> not ok - 94 grep -E -F -G pattern

"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

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

[Brian Gernhardt]

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

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

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.

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

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

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

[Michał Kiedrowicz]

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

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

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!