From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:43
Brandon Casey [off-list ref] 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?
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=$(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
On Thu, May 7, 2009 at 4:48 AM, Junio C Hamano [off-list ref] wrote:
Brandon Casey [off-list ref] writes:
quoted
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?
On Thu, May 7, 2009 at 4:48 AM, Junio C Hamano [off-list ref] wrote:
quoted
Brandon Casey [off-list ref] writes:
quoted
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=$(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