t2003: work around path mangling issue on Windows
PATCH 1/1 t2003: work around path mangling issue on Windows
From: Johannes Sixt <[email protected]>
MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an absolute path after an assignment, and mangles it to a C:/something string. Do not attract bash's attention by avoiding the equals sign.
--- t/t2003-checkout-cache-mkdir.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
t/t2003-checkout-cache-mkdir.sh +2 -2
@@ -94,14 +94,14 @@ test_expect_success 'apply filter from working tree .gitattributes with --prefix rm -fr path0 path1 path2 tmp* && mkdir path1 && mkdir tmp && - git config filter.replace-all.smudge "sed -e s/./=/g" && + git config filter.replace-all.smudge "sed -e s/./,/g" && git config filter.replace-all.clean cat && git config filter.replace-all.required true && echo "file1 filter=replace-all" >path1/.gitattributes && git checkout-index --prefix=tmp/ -f -a && echo frotz >expected && test_cmp expected tmp/path0 && - echo ====== >expected && + echo ,,,,,, >expected && test_cmp expected tmp/path1/file1 '
Signature · 1 line
1.8.2.1433.g0074116
Quoted 5 lines · Johannes Sixt
From: Johannes Sixt <[email protected]>
MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an absolute path after an assignment, and mangles it to a C:/something string. Do not attract bash's attention by avoiding the equals sign.
If this breakage is about path mangling, I suspect it may be cleaner to work it around by not using / as the pattern separator, e.g.
sed -e s!.!=!g
Or perhaps use SHELL_PATH to point at a more reasonable implementation of shell that does not have such an idiocy?
Quoted 25 lines
Signed-off-by Johannes Sixt <[email protected]>--- t/t2003-checkout-cache-mkdir.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)t/t2003-checkout-cache-mkdir.sh +2
-2@@ -94,14 +94,14 @@ test_expect_success 'apply filter from working tree .gitattributes with --prefix rm -fr path0 path1 path2 tmp* && mkdir path1 && mkdir tmp && - git config filter.replace-all.smudge "sed -e s/./=/g" && + git config filter.replace-all.smudge "sed -e s/./,/g" && git config filter.replace-all.clean cat && git config filter.replace-all.required true && echo "file1 filter=replace-all" >path1/.gitattributes && git checkout-index --prefix=tmp/ -f -a && echo frotz >expected && test_cmp expected tmp/path0 && - echo ====== >expected && + echo ,,,,,, >expected && test_cmp expected tmp/path1/file1 '
Am 3/20/2013 18:10, schrieb Junio C Hamano:
Quoted 4 lines
Quoted 2 lines · Johannes Sixt
From: Johannes Sixt <[email protected]>
Quoted 8 lines
Quoted 3 lines
MSYS bash considers the part "/g" in the sed expression "s/./=/g" as an absolute path after an assignment, and mangles it to a C:/something string. Do not attract bash's attention by avoiding the equals sign.
If this breakage is about path mangling, I suspect it may be cleaner to work it around by not using / as the pattern separator, e.g.
sed -e s!.!=!g
Half a year down the road you'd scratch your head why you were not using '/' as separator. As the replacement character is irrelevant here, it's better to exchange that. Therefore, I still prefer my version.
Quoted 2 lines
Or perhaps use
SHELL_PATHto point at a more reasonable implementation of shell that does not have such an idiocy?
Well, POSIX and DOS paths look inherently different, particularly absolute paths. You can't write a reasonably portable shell script if the shell doesn't help in some way.
Not to mention that the supply of POSIX shells on Windows is inherently scarce.
-- Hannes