shell compatibility issues with SunOS 5.10

shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

Hi,

I did "make test" on a SunOS 5.10 and it failed. With the below patch,
only t7400 and t8005 kept failing. For the first case, t7400.5 failed
because extensive use of sed to normalize path in git-submodule.sh

	# normalize path:
	# multiple //; leading ./; /./; /../; trailing /
	path=$(printf '%s/\n' "$path" |
		sed -e '
			s|//*|/|g
			s|^\(\./\)*||
			s|/\./|/|g
			:start
			s|\([^/]*\)/\.\./||
			tstart
			s|/*$||
		')

The second failed because it used extended regexp

grep "^\(author\|summary\) "

I'm no sed/grep wizard (and quite new to SunOS too), no clue how to do
it properly. Any help?

diff --git a/git-am.sh b/git-am.sh
index 6d1848b..5a91d52 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -46,7 +46,7 @@ fi
 sq () {
 	for sqarg
 	do
-		printf "%s" "$sqarg" |
+		printf "%s\n" "$sqarg" |
 		sed -e 's/'\''/'\''\\'\'''\''/g' -e 's/.*/ '\''&'\''/'
 	done
 }
diff --git a/t/t2019-checkout-sparse.sh b/t/t2019-checkout-sparse.sh
index 4ea1ee6..6949a59 100755
--- a/t/t2019-checkout-sparse.sh
+++ b/t/t2019-checkout-sparse.sh
@@ -68,13 +68,13 @@ test_expect_success 'update narrow prefix with modification' '
 	test -f work1/one &&
 	test -f work2/two &&
 	! test -f work3/three &&
-	grep -q modified work2/two &&
+	grep modified work2/two &&
 
 	! git checkout --sparse=work1/:work3/ &&
 	test -f work1/one &&
 	test -f work2/two &&
 	! test -f work3/three &&
-	grep -q modified work2/two &&
+	grep modified work2/two &&
 	git checkout work2/two
 '
 
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index b68ab11..61ccdee 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
 	test_must_fail git merge first
 '
 
-sha1=$(sed -e 's/	.*//' .git/MERGE_RR)
+sha1=$(cut -f 1 .git/MERGE_RR)
 rr=.git/rr-cache/$sha1
 test_expect_success 'recorded preimage' "grep ^=======$ $rr/preimage"
 
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index e2aa254..9a916d3 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -315,7 +315,7 @@ test_expect_success 'unpacking with --strict' '
 	head -n 10 LIST | git update-index --index-info &&
 	LI=$(git write-tree) &&
 	rm -f .git/index &&
-	tail -n 10 LIST | git update-index --index-info &&
+	tail -10 LIST | git update-index --index-info &&
 	ST=$(git write-tree) &&
 	PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
 		git pack-objects test-5 ) &&
@@ -362,7 +362,7 @@ test_expect_success 'index-pack with --strict' '
 	head -n 10 LIST | git update-index --index-info &&
 	LI=$(git write-tree) &&
 	rm -f .git/index &&
-	tail -n 10 LIST | git update-index --index-info &&
+	tail -10 LIST | git update-index --index-info &&
 	ST=$(git write-tree) &&
 	PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
 		git pack-objects test-5 ) &&
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index e2ef532..b3633d0 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -142,10 +142,10 @@ test_expect_success \
 	'editor not invoked if -F is given' '
 	 echo "moo" >file &&
 	 VISUAL=./editor git commit -a -F msg &&
-	 git show -s --pretty=format:"%s" | grep -q good &&
+	 git show -s --pretty=format:"%s" | grep good &&
 	 echo "quack" >file &&
 	 echo "Another good message." | VISUAL=./editor git commit -a -F - &&
-	 git show -s --pretty=format:"%s" | grep -q good
+	 git show -s --pretty=format:"%s" | grep good
 	 '
 # We could just check the head sha1, but checking each commit makes it
 # easier to isolate bugs.

Re: shell compatibility issues with SunOS 5.10

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> diff --git a/git-am.sh b/git-am.sh
> index 6d1848b..5a91d52 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -46,7 +46,7 @@ fi
>  sq () {
>  	for sqarg
>  	do
> -		printf "%s" "$sqarg" |
> +		printf "%s\n" "$sqarg" |
>  		sed -e 's/'\''/'\''\\'\'''\''/g' -e 's/.*/ '\''&'\''/'

I think this is a correct fix; according to POSIX sed is required only to
work on text files, so we should terminate its input with a newline.

> diff --git a/t/t2019-checkout-sparse.sh b/t/t2019-checkout-sparse.sh
> index 4ea1ee6..6949a59 100755
> --- a/t/t2019-checkout-sparse.sh
> +++ b/t/t2019-checkout-sparse.sh
> @@ -68,13 +68,13 @@ test_expect_success 'update narrow prefix with modification' '
> -	grep -q modified work2/two &&
> +	grep modified work2/two &&

Looks harmless (-q is in POSIX by the way), but you may want to redirect
the standard output to /dev/null instead (applies to your other rewrites
to "grep -q" as well).

> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> index b68ab11..61ccdee 100755
> --- a/t/t4200-rerere.sh
> +++ b/t/t4200-rerere.sh
> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>  	test_must_fail git merge first
>  '
>  
> -sha1=$(sed -e 's/	.*//' .git/MERGE_RR)
> +sha1=$(cut -f 1 .git/MERGE_RR)

I do not know why you need this one.  It shouldn't hurt, though.

> diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
> index e2aa254..9a916d3 100755
> --- a/t/t5300-pack-object.sh
> +++ b/t/t5300-pack-object.sh
> @@ -315,7 +315,7 @@ test_expect_success 'unpacking with --strict' '
>  	head -n 10 LIST | git update-index --index-info &&
>  	LI=$(git write-tree) &&
>  	rm -f .git/index &&
> -	tail -n 10 LIST | git update-index --index-info &&
> +	tail -10 LIST | git update-index --index-info &&

I do not know why your "head" apparently accepts -n (see the context) but
not your "tail"; as POSIX frowns upon head/tail -$number, this one is a
regression.

Re: shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

On Wed, May 6, 2009 at 4:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
>> index b68ab11..61ccdee 100755
>> --- a/t/t4200-rerere.sh
>> +++ b/t/t4200-rerere.sh
>> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>>       test_must_fail git merge first
>>  '
>>
>> -sha1=$(sed -e 's/    .*//' .git/MERGE_RR)
>> +sha1=$(cut -f 1 .git/MERGE_RR)
>
> I do not know why you need this one.  It shouldn't hurt, though.

Well because it wouldn't work without it. But on the other hand, I
grepped "sed.*\t" through and found many of them. Still wondering
while only this fails. I will look at it again when I have time.

>> diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
>> index e2aa254..9a916d3 100755
>> --- a/t/t5300-pack-object.sh
>> +++ b/t/t5300-pack-object.sh
>> @@ -315,7 +315,7 @@ test_expect_success 'unpacking with --strict' '
>>       head -n 10 LIST | git update-index --index-info &&
>>       LI=$(git write-tree) &&
>>       rm -f .git/index &&
>> -     tail -n 10 LIST | git update-index --index-info &&
>> +     tail -10 LIST | git update-index --index-info &&
>
> I do not know why your "head" apparently accepts -n (see the context) but
> not your "tail"; as POSIX frowns upon head/tail -$number, this one is a
> regression.
>

Hey, it's Sun's magic. head manpage mentions -n and it works (I
checked) while tail does not accept it. GNU tail's manpage does not
mention that it supports [+-]N syntax but it seems to work.
-- 
Duy

Re: shell compatibility issues with SunOS 5.10

[Johannes Sixt]

Nguyen Thai Ngoc Duy schrieb:
> I did "make test" on a SunOS 5.10 and it failed. With the below patch,
> only t7400 and t8005 kept failing. For the first case, t7400.5 failed
> because extensive use of sed to normalize path in git-submodule.sh
> 
> 	# normalize path:
> 	# multiple //; leading ./; /./; /../; trailing /
> 	path=$(printf '%s/\n' "$path" |
> 		sed -e '
> 			s|//*|/|g
> 			s|^\(\./\)*||
> 			s|/\./|/|g
> 			:start
> 			s|\([^/]*\)/\.\./||
> 			tstart
> 			s|/*$||
> 		')

There was a lengthy thread that lead to this version of the sed
expression. Could you please tell what your sed has to say about it? It
works even on AIX 4.3.3.

-- Hannes

Re: shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Nguyen Thai Ngoc Duy schrieb:
>> I did "make test" on a SunOS 5.10 and it failed. With the below patch,
>> only t7400 and t8005 kept failing. For the first case, t7400.5 failed
>> because extensive use of sed to normalize path in git-submodule.sh
>>
>>       # normalize path:
>>       # multiple //; leading ./; /./; /../; trailing /
>>       path=$(printf '%s/\n' "$path" |
>>               sed -e '
>>                       s|//*|/|g
>>                       s|^\(\./\)*||
>>                       s|/\./|/|g
>>                       :start
>>                       s|\([^/]*\)/\.\./||
>>                       tstart
>>                       s|/*$||
>>               ')
>
> There was a lengthy thread that lead to this version of the sed
> expression. Could you please tell what your sed has to say about it? It
> works even on AIX 4.3.3.

It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah"
is just wrong, (i.e. "./" remains). I stripped down to "sed -e
's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed
through sed manpage, seems no mention of bracket grouping.
-- 
Duy

Re: shell compatibility issues with SunOS 5.10

[Ralf Wildenhues]

Nguyen Thai Ngoc Duy writes:
> On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt wrote:
> > Nguyen Thai Ngoc Duy schrieb:
> >>       # normalize path:
> >>       # multiple //; leading ./; /./; /../; trailing /
> >>       path=$(printf '%s/\n' "$path" |
> >>               sed -e '
> >>                       s|//*|/|g
> >>                       s|^\(\./\)*||
> >>                       s|/\./|/|g
> >>                       :start
> >>                       s|\([^/]*\)/\.\./||
> >>                       tstart
> >>                       s|/*$||
> >>               ')

> It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah"
> is just wrong, (i.e. "./" remains). I stripped down to "sed -e
> 's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed
> through sed manpage, seems no mention of bracket grouping.

Quoting 'info Autoconf "Limitation of Usual Tools"':

     Some `sed' implementations, e.g., Solaris, restrict the special
     role of the asterisk to one-character regular expressions.  This
     may lead to unexpected behavior:

          $ echo '1*23*4' | /usr/bin/sed 's/\(.\)*/x/g'
          x2x4
          $ echo '1*23*4' | /usr/xpg4/bin/sed 's/\(.\)*/x/g'
          x

You can work around it in this case with
  :again
  s|^\./||
  t again

BTW, you should put a space between t and the label (but not between
: and label), POSIX requires that and some sed versions expect it.

Cheers,
Ralf

Re: shell compatibility issues with SunOS 5.10

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1852 bytes --]

Hi,

On Wed, 6 May 2009, Ralf Wildenhues wrote:

> Nguyen Thai Ngoc Duy writes:
> > On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt wrote:
> > > Nguyen Thai Ngoc Duy schrieb:
> > >>       # normalize path:
> > >>       # multiple //; leading ./; /./; /../; trailing /
> > >>       path=$(printf '%s/\n' "$path" |
> > >>               sed -e '
> > >>                       s|//*|/|g
> > >>                       s|^\(\./\)*||
> > >>                       s|/\./|/|g
> > >>                       :start
> > >>                       s|\([^/]*\)/\.\./||
> > >>                       tstart
> > >>                       s|/*$||
> > >>               ')
> 
> > It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah"
> > is just wrong, (i.e. "./" remains). I stripped down to "sed -e
> > 's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed
> > through sed manpage, seems no mention of bracket grouping.
> 
> Quoting 'info Autoconf "Limitation of Usual Tools"':
> 
>      Some `sed' implementations, e.g., Solaris, restrict the special
>      role of the asterisk to one-character regular expressions.  This
>      may lead to unexpected behavior:
> 
>           $ echo '1*23*4' | /usr/bin/sed 's/\(.\)*/x/g'
>           x2x4
>           $ echo '1*23*4' | /usr/xpg4/bin/sed 's/\(.\)*/x/g'
>           x
> 
> You can work around it in this case with
>   :again
>   s|^\./||
>   t again
> 
> BTW, you should put a space between t and the label (but not between
> : and label), POSIX requires that and some sed versions expect it.

Maybe the time is better spent on turning submodule into a builtin, before 
it gets even larger, and before we have to jump through even more hoops 
because of shell compatibility issues?

Ciao,
Dscho

Re: shell compatibility issues with SunOS 5.10

[Jeff King]

On Wed, May 06, 2009 at 03:59:13PM +1000, Nguyen Thai Ngoc Duy wrote:

> I did "make test" on a SunOS 5.10 and it failed. With the below patch,
> only t7400 and t8005 kept failing. For the first case, t7400.5 failed
> because extensive use of sed to normalize path in git-submodule.sh

You may consider putting /usr/xpg4/bin in your PATH. It has much more
sane versions of shell utilities (including a tail which supports "-n").

-Peff

Re: shell compatibility issues with SunOS 5.10

[Brandon Casey]

Nguyen Thai Ngoc Duy wrote:
> Hi,
> 
> I did "make test" on a SunOS 5.10 and it failed.

> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> index b68ab11..61ccdee 100755
> --- a/t/t4200-rerere.sh
> +++ b/t/t4200-rerere.sh
> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>  	test_must_fail git merge first
>  '
>  
> -sha1=$(sed -e 's/	.*//' .git/MERGE_RR)
> +sha1=$(cut -f 1 .git/MERGE_RR)

Are you using /bin/sed?  I think it has a problem with tabs.
/usr/xpg4/bin/sed works correctly, but it has a problem with
files that are not newline terminated.  So you will get other
errors.  I have a set of "ugly" patches that I will follow this
email with that allow me to compile on Solaris 10 while skipping
the following tests:

   GIT_SKIP_TESTS='
      t3900.2[23]
      t3901.[67]
      t6030.1[23]
      t8005.*
   '

The t3900 and t3901 are due to iconv failures.

The t6030 issues are due to a flaw in Sun's ksh, i.e. /usr/xpg4/bin/sh
which I use for testing.  This ksh seems to only call a trap that is
set within at most the next outer-layer function.  In other words, if
func1 sets a trap, and calls func2 which calls func3 which exits, then
the trap in func1 will _not_ be called. If instead, func2 exits, then
the trap will be called.  Bisect does such a thing.  You should not
have a problem with other ksh or bash.

I had assumed t8005 was failing because of iconv, but since you have
pointed out the extended RE in grep, some of these should pass.
Converting to egrep allows tests 1, 4 and 5 to pass for me. So my skip
expression can be changed to t8005.[23].

>  rr=.git/rr-cache/$sha1
>  test_expect_success 'recorded preimage' "grep ^=======$ $rr/preimage"

Patches to follow.

-brandon

[PATCH 0/4] workaround some Solaris sed issues

[Brandon Casey]

Here are 4 patches that I have been using to work around the issue that
sed on Solaris exits non-zero if it's input is not newline terminated.

The first two patches are signed-off-on and I think can be applied to
git.git.

The last two are kludges which Junio may not want to apply and maybe
someone has a better work around for.

Brandon Casey (4):
  t4118: add missing '&&'
  t4118: avoid sed invocation on file without terminating newline
  t/annotate-tests.sh: avoid passing a non-newline terminated file to
    sed
  t4200: avoid passing a non-newline terminated file to sed

 t/annotate-tests.sh            |    5 ++++-
 t/t4118-apply-empty-context.sh |    4 ++--
 t/t4200-rerere.sh              |    2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

[PATCH 1/4] t4118: add missing '&&'

[Brandon Casey]

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/t4118-apply-empty-context.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t4118-apply-empty-context.sh b/t/t4118-apply-empty-context.sh
index f92e259..314bc6e 100755
--- a/t/t4118-apply-empty-context.sh
+++ b/t/t4118-apply-empty-context.sh
@@ -20,7 +20,7 @@ test_expect_success setup '
 		cat file1 &&
 		echo Q | tr -d "\\012"
 	} >file2 &&
-	cat file2 >file2.orig
+	cat file2 >file2.orig &&
 	git add file1 file2 &&
 	sed -e "/^B/d" <file1.orig >file1 &&
 	sed -e "/^[BQ]/d" <file2.orig >file2 &&
-- 
1.6.2.4.24.gde59d2

[PATCH 2/4] t4118: avoid sed invocation on file without terminating newline

[Brandon Casey]

Some versions of sed exit non-zero if the file they are supplied is not
newline terminated. Solaris's /usr/xpg4/bin/sed is one such sed.  In
this case the sed invocation can be avoided entirely since the resulting
file is equivalent to a previously created file.  So, just copy that file
into place instead.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/t4118-apply-empty-context.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t4118-apply-empty-context.sh b/t/t4118-apply-empty-context.sh
index 314bc6e..65f2e4c 100755
--- a/t/t4118-apply-empty-context.sh
+++ b/t/t4118-apply-empty-context.sh
@@ -23,7 +23,7 @@ test_expect_success setup '
 	cat file2 >file2.orig &&
 	git add file1 file2 &&
 	sed -e "/^B/d" <file1.orig >file1 &&
-	sed -e "/^[BQ]/d" <file2.orig >file2 &&
+	cat file1 > file2 &&
 	echo Q | tr -d "\\012" >>file2 &&
 	cat file1 >file1.mods &&
 	cat file2 >file2.mods &&
-- 
1.6.2.4.24.gde59d2

[PATCH 3/4] t/annotate-tests.sh: avoid passing a non-newline terminated file to sed

[Brandon Casey]

Some versions of sed exit non-zero if the file they are supplied is not
newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
rework this test to avoid doing so.

This affects tests t8001-annotate.sh and t8002-blame.sh.
---
 t/annotate-tests.sh |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index cacb273..396b965 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -114,7 +114,10 @@ test_expect_success \
 test_expect_success \
     'some edit' \
     'mv file file.orig &&
-    sed -e "s/^3A/99/" -e "/^1A/d" -e "/^incomplete/d" < file.orig > file &&
+    {
+	cat file.orig &&
+	echo
+    } | sed -e "s/^3A/99/" -e "/^1A/d" -e "/^incomplete/d" > file &&
     echo "incomplete" | tr -d "\\012" >>file &&
     GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
 
-- 
1.6.2.4.24.gde59d2

[PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Brandon Casey]

Some versions of sed exit non-zero if the file they are supplied is not
newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
rework this test to avoid doing so.
---
 t/t4200-rerere.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index b68ab11..48dbd8e 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -190,7 +190,7 @@ test_expect_success 'file2 added differently in two branches' '
 	git add file2 &&
 	git commit -m version2 &&
 	test_must_fail git merge fourth &&
-	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
+	sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/	.*//") &&
 	rr=.git/rr-cache/$sha1 &&
 	echo Cello > file2 &&
 	git add file2 &&
-- 
1.6.2.4.24.gde59d2

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Some versions of sed exit non-zero if the file they are supplied is not
> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
> rework this test to avoid doing so.

I think up to your 3/4 is reasonable, but this is not enough for POSIX
conformance (it is Ok if it is just aiming to fix "Solaris quirk").  POSIX
sed is only required to work on text files, but .git/MERGE_RR is not a
text file (it is a sequence of NUL terminated records).

I think something like this may work better.  Can somebody test?

> -	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
> +	sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/	.*//") &&

	sha1=$(tr "\\000" "\\012" <./git/MERGE_RR | sed -e "s/	.*//") &&

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Brandon Casey]

Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> Some versions of sed exit non-zero if the file they are supplied is not
>> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
>> rework this test to avoid doing so.
> 
> I think up to your 3/4 is reasonable, but this is not enough for POSIX
> conformance (it is Ok if it is just aiming to fix "Solaris quirk").  POSIX
> sed is only required to work on text files, but .git/MERGE_RR is not a
> text file (it is a sequence of NUL terminated records).
> 
> I think something like this may work better.  Can somebody test?
> 
>> -	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
>> +	sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/	.*//") &&
> 
> 	sha1=$(tr "\\000" "\\012" <./git/MERGE_RR | sed -e "s/	.*//") &&

I was about to reply that this fix works fine (actually, I was about to
reply over an hour ago but was interrupted).

But, while testing it I noticed that you had a typo in your version that
_did_not_ cause the test to fail.  You have an extra slash in the path
to '.git/MERGE_RR' which would have caused sha1 to be unset.

The 'sha1' variable that is set here on line 193 is used on the next line
to set 'rr', but 'rr' is never used again.  Unless I'm missing something,
it appears these two lines can be deleted.

-brandon

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> The 'sha1' variable that is set here on line 193 is used on the next line
> to set 'rr', but 'rr' is never used again.  Unless I'm missing something,
> it appears these two lines can be deleted.

Yeah, it looks like this is a mindless cut&paste; I do not see the point
of setting rr there unless it is used to make sure that a corresponding
rerere cache is created, or something.

[PATCH 1/2] t4200: remove two unnecessary lines

[Brandon Casey]

These two lines appear to be unnecessary.  They set variables which are not
used afterwards.  The primary motivation to remove them is that the sed
invocation exits non-zero for seds which require newline termination of
input files.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 t/t4200-rerere.sh |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index b68ab11..504802c 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -190,8 +190,6 @@ test_expect_success 'file2 added differently in two branches' '
 	git add file2 &&
 	git commit -m version2 &&
 	test_must_fail git merge fourth &&
-	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
-	rr=.git/rr-cache/$sha1 &&
 	echo Cello > file2 &&
 	git add file2 &&
 	git commit -m resolution
-- 
1.6.2.4.24.gde59d2

[PATCH 2/2] t4200: convert sed expression which operates on non-text file to perl

[Brandon Casey]

POSIX only requires sed to work on text files and MERGE_RR is not a text
file.  Some versions of sed complain that this file is not newline
terminated, and exit non-zero.  Use perl instead which does not have a
problem with it.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


Initially, I changed this to use the tr workaround Junio suggested, so it
looked like this:

   sha1=$(tr '\000' '\012' <.git/MERGE_RR | sed -e 's/	.*//')

Then I noticed Jeff King's commit e85fe4d8 which changed uses of tr to perl
for portability's sake.  So the line became:

   sha1=$(perl -pe 'y/\000/\012/' .git/MERGE_RR | sed -e 's/	.*//')

Then I thought, "Why call sed?  I already started up perl, let _it_ do the
substitution.", so it became:

   sha1=$(perl -pe 'y/\000/\012/; s/	.*//' .git/MERGE_RR)

And then I thought, "Why do I need the transliteration?".  So we end up
with this simple patch.

-brandon


 t/t4200-rerere.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index 504802c..5a1721d 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
 	test_must_fail git merge first
 '
 
-sha1=$(sed -e 's/	.*//' .git/MERGE_RR)
+sha1=$(perl -pe 's/	.*//' .git/MERGE_RR)
 rr=.git/rr-cache/$sha1
 test_expect_success 'recorded preimage' "grep ^=======$ $rr/preimage"
 
-- 
1.6.2.4.24.gde59d2

Re: shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

On Wed, May 6, 2009 at 7:38 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 6 May 2009, Ralf Wildenhues wrote:
>
>> Nguyen Thai Ngoc Duy writes:
>> > On Wed, May 6, 2009 at 4:45 PM, Johannes Sixt wrote:
>> > > Nguyen Thai Ngoc Duy schrieb:
>> > >>       # normalize path:
>> > >>       # multiple //; leading ./; /./; /../; trailing /
>> > >>       path=$(printf '%s/\n' "$path" |
>> > >>               sed -e '
>> > >>                       s|//*|/|g
>> > >>                       s|^\(\./\)*||
>> > >>                       s|/\./|/|g
>> > >>                       :start
>> > >>                       s|\([^/]*\)/\.\./||
>> > >>                       tstart
>> > >>                       s|/*$||
>> > >>               ')
>>
>> > It says nothing. The result of "printf '%s\n' ./foo/bar | sed -e blah"
>> > is just wrong, (i.e. "./" remains). I stripped down to "sed -e
>> > 's|^\(\./\)*||'", does not work. Probably due to \( \) pair. Skimmed
>> > through sed manpage, seems no mention of bracket grouping.
>>
>> Quoting 'info Autoconf "Limitation of Usual Tools"':
>>
>>      Some `sed' implementations, e.g., Solaris, restrict the special
>>      role of the asterisk to one-character regular expressions.  This
>>      may lead to unexpected behavior:
>>
>>           $ echo '1*23*4' | /usr/bin/sed 's/\(.\)*/x/g'
>>           x2x4
>>           $ echo '1*23*4' | /usr/xpg4/bin/sed 's/\(.\)*/x/g'
>>           x
>>
>> You can work around it in this case with
>>   :again
>>   s|^\./||
>>   t again
>>
>> BTW, you should put a space between t and the label (but not between
>> : and label), POSIX requires that and some sed versions expect it.
>
> Maybe the time is better spent on turning submodule into a builtin, before
> it gets even larger, and before we have to jump through even more hoops
> because of shell compatibility issues?

Totally agree. git-submodule is the second largest shell script.
Better do it now or it will take git-rebase--interactive position as
the biggest one.
-- 
Duy

Re: shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

On Thu, May 7, 2009 at 4:14 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> Nguyen Thai Ngoc Duy wrote:
>> Hi,
>>
>> I did "make test" on a SunOS 5.10 and it failed.
>
>> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
>> index b68ab11..61ccdee 100755
>> --- a/t/t4200-rerere.sh
>> +++ b/t/t4200-rerere.sh
>> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>>       test_must_fail git merge first
>>  '
>>
>> -sha1=$(sed -e 's/    .*//' .git/MERGE_RR)
>> +sha1=$(cut -f 1 .git/MERGE_RR)
>
> Are you using /bin/sed?  I think it has a problem with tabs.

Yes I use /bin/sed. if /usr/xpg4/bin/sed is recommended, test-lib.sh
should set up PATH automatically, I think.
-- 
Duy

Re: [PATCH 2/2] t4200: convert sed expression which operates on non-text file to perl

[Nguyen Thai Ngoc Duy]

On Thu, May 7, 2009 at 8:56 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> index 504802c..5a1721d 100755
> --- a/t/t4200-rerere.sh
> +++ b/t/t4200-rerere.sh
> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>        test_must_fail git merge first
>  '
>
> -sha1=$(sed -e 's/      .*//' .git/MERGE_RR)
> +sha1=$(perl -pe 's/    .*//' .git/MERGE_RR)

Can we have a wrapper for this please? This is correction solution.
But my work to make git work on windows without msys/cygwin also means
that I don't have perl. Maybe something like this? I know perl regex
and sed one is not completely compatible, but it should work for
simple regex used here and elsewhere.

sed_wrapper() {
  if test_have_prereq PERL; then
    perl -pe "$@"
  else
    sed -e "$@"
  fi
}
-- 
Duy

Re: shell compatibility issues with SunOS 5.10

[Brandon Casey]

Nguyen Thai Ngoc Duy wrote:
> On Thu, May 7, 2009 at 4:14 AM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Nguyen Thai Ngoc Duy wrote:
>>> Hi,
>>>
>>> I did "make test" on a SunOS 5.10 and it failed.
>>> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
>>> index b68ab11..61ccdee 100755
>>> --- a/t/t4200-rerere.sh
>>> +++ b/t/t4200-rerere.sh
>>> @@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
>>>       test_must_fail git merge first
>>>  '
>>>
>>> -sha1=$(sed -e 's/    .*//' .git/MERGE_RR)
>>> +sha1=$(cut -f 1 .git/MERGE_RR)
>> Are you using /bin/sed?  I think it has a problem with tabs.
> 
> Yes I use /bin/sed. if /usr/xpg4/bin/sed is recommended, test-lib.sh
> should set up PATH automatically, I think.

/usr/xpg*/bin is where Sun puts the POSIX compliant versions of standard
system utilities.

The binaries in /bin/ retain their historical Solaris behavior.

Check out the XPG4 man page on a sun.

Not sure about the best route to take here.  /usr/xpg4/bin should probably
be in the user's PATH when git is executed too.

-brandon

Re: shell compatibility issues with SunOS 5.10

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> /usr/xpg*/bin is where Sun puts the POSIX compliant versions of standard
> system utilities.
>
> The binaries in /bin/ retain their historical Solaris behavior.
>
> Check out the XPG4 man page on a sun.
>
> Not sure about the best route to take here.  /usr/xpg4/bin should probably
> be in the user's PATH when git is executed too.

I doubt it is limited to git.

My experience from the days I had to do things on Solaris boxes several
years ago was that it was the only way to have a workable environment to
have /usr/xpg*/bin on my PATH.

If the contents of the stock /usr/bin has been frozen at the historical
state while the outside world made progress, I would imagine that the
situation has gotten worse for people who still use tools from /usr/bin
and expect their scripts to be portable with anybody else.

On Solaris, I expect everybody to build git with SHELL_PATH set to
something other than /bin/sh, and binary packaged one (I do not know
Solaris have such a packaging system, though) would also be set to avoid
the broken /bin/sh.  I suspect you could do something like this...

 Makefile        |   13 +++++++++++++
 git-sh-setup.sh |    2 ++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 6e21643..081f06a 100644
--- a/Makefile
+++ b/Makefile
@@ -3,6 +3,11 @@ all::
 
 # Define V=1 to have a more verbose compile.
 #
+# Define SHELL_PATH to a POSIX shell if your /bin/sh is broken.
+#
+# Define SANE_TOOL_PATH to a colon-separated list of paths to prepend
+# to PATH if your tools in /usr/bin are broken.
+#
 # Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
 # or vsnprintf() return -1 instead of number of characters which would
 # have been written to the final string if enough space had been available.
@@ -694,6 +699,7 @@ ifeq ($(uname_S),SunOS)
 	NEEDS_SOCKET = YesPlease
 	NEEDS_NSL = YesPlease
 	SHELL_PATH = /bin/bash
+	SANE_TOOL_PATH = /usr/xpg5/bin:/usr/xpg4/bin
 	NO_STRCASESTR = YesPlease
 	NO_MEMMEM = YesPlease
 	NO_HSTRERROR = YesPlease
@@ -852,6 +858,12 @@ endif
 -include config.mak.autogen
 -include config.mak
 
+ifdef SANE_TOOL_PATH
+BROKEN_PATH_FIX = s|^. @@PATH@@|PATH=$(SANE_TOOL_PATH)|
+else
+BROKEN_PATH_FIX = d
+endif
+
 ifeq ($(uname_S),Darwin)
 	ifndef NO_FINK
 		ifeq ($(shell test -d /sw/lib && echo y),y)
@@ -1251,6 +1263,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
 	    -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+	    -e '/^# @@PATH@@/$(BROKEN_PATH_FIX)' \
 	    $@.sh >$@+ && \
 	chmod +x $@+ && \
 	mv $@+ $@
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 8382339..7802581 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -11,6 +11,8 @@
 # exporting it.
 unset CDPATH
 
+# @@PATH@@:$PATH
+
 die() {
 	echo >&2 "$@"
 	exit 1

Re: shell compatibility issues with SunOS 5.10

[Nguyen Thai Ngoc Duy]

On Wed, May 6, 2009 at 4:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
>> index e2aa254..9a916d3 100755
>> --- a/t/t5300-pack-object.sh
>> +++ b/t/t5300-pack-object.sh
>> @@ -315,7 +315,7 @@ test_expect_success 'unpacking with --strict' '
>>       head -n 10 LIST | git update-index --index-info &&
>>       LI=$(git write-tree) &&
>>       rm -f .git/index &&
>> -     tail -n 10 LIST | git update-index --index-info &&
>> +     tail -10 LIST | git update-index --index-info &&
>
> I do not know why your "head" apparently accepts -n (see the context) but
> not your "tail"; as POSIX frowns upon head/tail -$number, this one is a
> regression.
>

I digged back in history and found Jeff's b4ce54fc, so my approach is
wrong too. Does it have to be exactly ten last lines? If it's just one
or two lines, then sed -ne '$p' can be used.
-- 
Duy

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Nguyen Thai Ngoc Duy]

On Thu, May 7, 2009 at 4:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Some versions of sed exit non-zero if the file they are supplied is not
>> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
>> rework this test to avoid doing so.
>
> I think up to your 3/4 is reasonable, but this is not enough for POSIX
> conformance (it is Ok if it is just aiming to fix "Solaris quirk").  POSIX
> sed is only required to work on text files, but .git/MERGE_RR is not a
> text file (it is a sequence of NUL terminated records).
>
> I think something like this may work better.  Can somebody test?
>
>> -     sha1=$(sed -e "s/       .*//" .git/MERGE_RR) &&
>> +     sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/        .*//") &&
>
>        sha1=$(tr "\\000" "\\012" <./git/MERGE_RR | sed -e "s/  .*//") &&
>

I would replace it again, according to e85fe4d8.
-- 
Duy

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Brandon Casey]

Nguyen Thai Ngoc Duy wrote:
> On Thu, May 7, 2009 at 4:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>>
>>> Some versions of sed exit non-zero if the file they are supplied is not
>>> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
>>> rework this test to avoid doing so.
>> I think up to your 3/4 is reasonable, but this is not enough for POSIX
>> conformance (it is Ok if it is just aiming to fix "Solaris quirk").  POSIX
>> sed is only required to work on text files, but .git/MERGE_RR is not a
>> text file (it is a sequence of NUL terminated records).
>>
>> I think something like this may work better.  Can somebody test?
>>
>>> -     sha1=$(sed -e "s/       .*//" .git/MERGE_RR) &&
>>> +     sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/        .*//") &&
>>        sha1=$(tr "\\000" "\\012" <./git/MERGE_RR | sed -e "s/  .*//") &&
>>
> 
> I would replace it again, according to e85fe4d8.

The line referenced above will actually be deleted unless someone chimes
in and says it is needed.

The commit you referenced was taken into account in the patch for the other
use of sed on .git/MERGE_RR in the same test script:
"[PATCH 2/2] t4200: convert sed expression which operates on non-text-file to perl"

-brandon

Re: shell compatibility issues with SunOS 5.10

[Brandon Casey]

I like it.  The PATH would still need to be set up properly
for the tests though.  Either test-lib should handle SANE_TOOL_PATH
or Makefile could export PATH like

ifdef SANE_TOOL_PATH
  PATH := $(SANE_TOOL_PATH):${PATH}

-brandon


Junio C Hamano wrote:

> I suspect you could do something like this...

>  Makefile        |   13 +++++++++++++
>  git-sh-setup.sh |    2 ++
>  2 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 6e21643..081f06a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3,6 +3,11 @@ all::
>  
>  # Define V=1 to have a more verbose compile.
>  #
> +# Define SHELL_PATH to a POSIX shell if your /bin/sh is broken.
> +#
> +# Define SANE_TOOL_PATH to a colon-separated list of paths to prepend
> +# to PATH if your tools in /usr/bin are broken.
> +#
>  # Define SNPRINTF_RETURNS_BOGUS if your are on a system which snprintf()
>  # or vsnprintf() return -1 instead of number of characters which would
>  # have been written to the final string if enough space had been available.
> @@ -694,6 +699,7 @@ ifeq ($(uname_S),SunOS)
>  	NEEDS_SOCKET = YesPlease
>  	NEEDS_NSL = YesPlease
>  	SHELL_PATH = /bin/bash
> +	SANE_TOOL_PATH = /usr/xpg5/bin:/usr/xpg4/bin
>  	NO_STRCASESTR = YesPlease
>  	NO_MEMMEM = YesPlease
>  	NO_HSTRERROR = YesPlease
> @@ -852,6 +858,12 @@ endif
>  -include config.mak.autogen
>  -include config.mak
>  
> +ifdef SANE_TOOL_PATH
> +BROKEN_PATH_FIX = s|^. @@PATH@@|PATH=$(SANE_TOOL_PATH)|
> +else
> +BROKEN_PATH_FIX = d
> +endif
> +
>  ifeq ($(uname_S),Darwin)
>  	ifndef NO_FINK
>  		ifeq ($(shell test -d /sw/lib && echo y),y)
> @@ -1251,6 +1263,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
>  	    -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
>  	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
>  	    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
> +	    -e '/^# @@PATH@@/$(BROKEN_PATH_FIX)' \
>  	    $@.sh >$@+ && \
>  	chmod +x $@+ && \
>  	mv $@+ $@
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index 8382339..7802581 100755
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -11,6 +11,8 @@
>  # exporting it.
>  unset CDPATH
>  
> +# @@PATH@@:$PATH
> +
>  die() {
>  	echo >&2 "$@"
>  	exit 1
> 
> 

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> Nguyen Thai Ngoc Duy wrote:
>> On Thu, May 7, 2009 at 4:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>>>
>>>> Some versions of sed exit non-zero if the file they are supplied is not
>>>> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
>>>> rework this test to avoid doing so.
>>> I think up to your 3/4 is reasonable, but this is not enough for POSIX
>>> conformance (it is Ok if it is just aiming to fix "Solaris quirk").  POSIX
>>> sed is only required to work on text files, but .git/MERGE_RR is not a
>>> text file (it is a sequence of NUL terminated records).
>>>
>>> I think something like this may work better.  Can somebody test?
>>>
>>>> -     sha1=$(sed -e "s/       .*//" .git/MERGE_RR) &&
>>>> +     sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/        .*//") &&
>>>        sha1=$(tr "\\000" "\\012" <./git/MERGE_RR | sed -e "s/  .*//") &&
>
> The line referenced above will actually be deleted unless someone chimes
> in and says it is needed.

I've already removed it; thanks.

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Johannes Sixt]

Brandon Casey schrieb:
> Some versions of sed exit non-zero if the file they are supplied is not
> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
> rework this test to avoid doing so.
> ---
>  t/t4200-rerere.sh |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> index b68ab11..48dbd8e 100755
> --- a/t/t4200-rerere.sh
> +++ b/t/t4200-rerere.sh
> @@ -190,7 +190,7 @@ test_expect_success 'file2 added differently in two branches' '
>  	git add file2 &&
>  	git commit -m version2 &&
>  	test_must_fail git merge fourth &&
> -	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
> +	sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/	.*//") &&

Couldn't that line become

	sha1=$(cat .git/MERGE_RR) &&
	sha1=%{sha1%%	*} &&

(a literal tab before the '*')?

-- Hannes

Re: [PATCH 4/4] t4200: avoid passing a non-newline terminated file to sed

[Brandon Casey]

Johannes Sixt wrote:
> Brandon Casey schrieb:
>> Some versions of sed exit non-zero if the file they are supplied is not
>> newline terminated.  Solaris's /usr/xpg4/bin/sed is one such sed.  So
>> rework this test to avoid doing so.
>> ---
>>  t/t4200-rerere.sh |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
>> index b68ab11..48dbd8e 100755
>> --- a/t/t4200-rerere.sh
>> +++ b/t/t4200-rerere.sh
>> @@ -190,7 +190,7 @@ test_expect_success 'file2 added differently in two branches' '
>>  	git add file2 &&
>>  	git commit -m version2 &&
>>  	test_must_fail git merge fourth &&
>> -	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
>> +	sha1=$({ cat .git/MERGE_RR; echo; } | sed -e "s/	.*//") &&
> 
> Couldn't that line become
> 
> 	sha1=$(cat .git/MERGE_RR) &&
> 	sha1=%{sha1%%	*} &&
> 
> (a literal tab before the '*')?

Yes, that works here.  The line above has been removed so it's moot for
this case.  Your change could be applied at line 60 of t4200-rerere.sh to
replace my perl call that was just applied if you think it is worth it.

-brandon