On 12-04-17 03:53 AM, Zbigniew Jędrzejewski-Szmek wrote: > On 04/17/2012 12:34 AM, Jonathan Nieder wrote: >> marcnarc@xxxxxxxxxxx wrote: >> >>> + grep descriptive-branch actual | grep "[new branch]"&& >>> + grep descriptive-tag actual | grep "[new tag]"&& >>> + grep others/crazy actual | grep "[new ref]" >> >> Careful. :) I suppose the simplest fix would be to leave out the >> brackets so the '[new ref]' tag is not misinterpreted as a character >> class, like so: >> >> grep "new branch.*descriptive-branch" actual&& >> grep "new tag.*descriptive-tag" actual&& >> grep "new ref.*others/crazy" actual > > s/grep/test_i18ngrep/ With the switch to test_i18ngrep do I have to worry about possible regexp misinterpretations of "[new branch]" et al? Jonathan, I figured regexps aren't an issue with plain "grep" (unlike "egrep" or "grep -e"). I take it this is a portability concern -- are there systems that actually replace plain "grep" like a "egrep"? Also, in my test's pipes I believe only the second "grep" needs to be "test_i18ngrep", right? (Only strings like "[new branch]" are internationalized.) > Also: >>> + echo "Nuts" >> crazy && >>> + git add crazy && >>> + git commit -a -m "descriptive commit" && >>> + git update-ref refs/others/crazy HEAD && >>> + ( >>> + cd descriptive && >>> + git fetch o 2> actual > redirections should be without spaces between '>' and the filename > (>>crazy, 2>actual), for portability. Consistency; got it. Thanks guys! M. -- 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