{"thread":{"id":"8314","subject":"Bug: git-rebase goofs up \\n in commit messages","startedAt":"2007-05-25T21:11:26Z","lastAt":"2007-05-26T07:47:09Z","messageCount":13,"participants":["Szekeres Istvan","Jeff King","Herbert Xu","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"43294","messageId":"465750FE.9000406@iii.hu","threadId":"8314","inReplyTo":null,"subject":"Bug: git-rebase goofs up \\n in commit messages","fromName":"Szekeres Istvan","fromEmail":"szekeres@iii.hu","sentAt":"2007-05-25T21:11:26Z","receivedAt":"2007-05-25T21:11:26Z","isPatch":false,"sender":{"key":"szekeres@iii.hu","avatar":null},"body":"Hello,\n\nwhile playing with git I found the following bug: if a commit message\ncontains \"\\n\" (as a string, not as a character), git-rebase changes this\nstring into a literal newline character.\n\nThis is how to reproduce it:\n\nmkdir tmp\ncd tmp\ngit init-db\necho xx > xx.txt\ngit add xx.txt\ngit commit -m foo\necho xx >> xx.txt\ngit add xx.txt\ngit commit -m foo\ngit branch other 'HEAD^'\ngit checkout other\necho yy > yy.txt\ngit add yy.txt\ngit commit -m 'foo \\\\n bar'\ngit log 'HEAD^..'              [1]\ngit rebase master\ngit log 'HEAD^..'              [2]\n\nThe output of [1] is the following (correctly):\n\ncommit 694daa542b83dc1bbd6c070630f73c9a111f6e40\nAuthor: Istvan Szekeres <szekeres@iii.hu>\nDate:   Fri May 25 23:09:32 2007 +0200\n\n    foo \\n bar\n\n\nThe output of [2] is the following (wrong!):\ncommit 68ba80d2927d4e21c7a1d1d758f9023dbe063bde\nAuthor: Istvan Szekeres <szekeres@iii.hu>\nDate:   Fri May 25 22:58:28 2007 +0200\n\n    foo\n     bar\n....\n\nI think this is a bug.\n\nBest regards,\nIstvan\n\n\n\n\n\n"},{"id":"43311","messageId":"20070526004028.GA8940@sigill.intra.peff.net","threadId":"8314","inReplyTo":"465750FE.9000406@iii.hu","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-26T00:40:28Z","receivedAt":"2007-05-26T00:40:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 25, 2007 at 11:11:26PM +0200, Szekeres Istvan wrote:\n\n> while playing with git I found the following bug: if a commit message\n> contains \"\\n\" (as a string, not as a character), git-rebase changes this\n> string into a literal newline character.\n\nHmm. The culprit seems to be git-am.sh, line 313:\n\n  SUBJECT=\"$(sed -n '/^Subject/ s/Subject: //p' \"$dotest/info\")\"\n\nand even more exciting, it seems to be a bash vs dash thing. Try this:\n\n$ cat >content-with-escapes <<'EOF'\nfoo \\n bar\nEOF\n\n$ bash\nbash$ test=$(cat content-with-escapes)\nbash$ echo $test\nfoo \\n bar\n\n$ dash\ndash$ test=$(cat content-with-escapes)\ndash$ echo $test\nfoo\n bar\n\n\nHmm. It even happens with this:\n\nbash$ export test=$(echo foo \\\\n bar)\nbash$ dash\ndash$ echo $test\nfoo\n bar\n\nI'm not sure what the best workaround is.  I am cc'ing Herbert Xu to see\nif he has any helpful comments.\n\n-Peff\n"},{"id":"43315","messageId":"20070526011036.GA4169@gondor.apana.org.au","threadId":"8314","inReplyTo":"20070526004028.GA8940@sigill.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2007-05-26T01:10:36Z","receivedAt":"2007-05-26T01:10:36Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"On Fri, May 25, 2007 at 08:40:28PM -0400, Jeff King wrote:\n> \n> Hmm. It even happens with this:\n> \n> bash$ export test=$(echo foo \\\\n bar)\n> bash$ dash\n> dash$ echo $test\n> foo\n>  bar\n> \n> I'm not sure what the best workaround is.  I am cc'ing Herbert Xu to see\n> if he has any helpful comments.\n\nIf you need to echo something that may have escapes in it, the portable\nway to do it is\n\nprintf '%s\\n' \"$test\"\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>\nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"},{"id":"43321","messageId":"20070526034236.GA18169@coredump.intra.peff.net","threadId":"8314","inReplyTo":"20070526011036.GA4169@gondor.apana.org.au","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-26T03:42:36Z","receivedAt":"2007-05-26T03:42:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 26, 2007 at 11:10:36AM +1000, Herbert Xu wrote:\n\n> If you need to echo something that may have escapes in it, the portable\n> way to do it is\n> \n> printf '%s\\n' \"$test\"\n\nAh, I see. I had thought the problem was coming from some dash\ninterpolation magic, but yes, it's just echo doing the conversion. And\nPOSIX is very clear that this is an implementation defined behavior.\nThanks very much for the response, Herbert.\n\nJunio, patch is below. I have no idea how prevalent this issue is within\nour scripts, but this at least fixes the reported bug.\n\n-- >8 --\ngit-am: use printf instead of echo on user-supplied strings\n\nUnder some implementations of echo (such as that provided by\ndash), backslash escapes are recognized without any other\noptions. This means that echo-ing user-supplied strings may\ncause any backslash sequences in them to be converted. Using\nprintf resolves the ambiguity.\n\nThis bug can be seen when using git-am to apply a patch\nwhose subject contains the character sequence \"\\n\"; the\ncharacters are converted to a literal newline. Noticed by\nSzekeres Istvan.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n git-am.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex c9f66e2..543efd0 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -331,7 +331,7 @@ do\n \t\tADD_SIGNOFF=\n \t    fi\n \t    {\n-\t\techo \"$SUBJECT\"\n+\t\tprintf '%s\\n' \"$SUBJECT\"\n \t\tif test -s \"$dotest/msg-clean\"\n \t\tthen\n \t\t\techo\n@@ -394,7 +394,7 @@ do\n \tfi\n \n \techo\n-\techo \"Applying '$SUBJECT'\"\n+\tprintf 'Applying %s\\n' \"$SUBJECT\"\n \techo\n \n \tcase \"$resolved\" in\n-- \n1.5.2.818.g9b59-dirty\n"},{"id":"43322","messageId":"7vwsywnske.fsf@assigned-by-dhcp.cox.net","threadId":"8314","inReplyTo":"20070526034236.GA18169@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-26T03:59:29Z","receivedAt":"2007-05-26T03:59:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sat, May 26, 2007 at 11:10:36AM +1000, Herbert Xu wrote:\n>\n>> If you need to echo something that may have escapes in it, the portable\n>> way to do it is\n>> \n>> printf '%s\\n' \"$test\"\n>\n> Ah, I see. I had thought the problem was coming from some dash\n> interpolation magic, but yes, it's just echo doing the conversion. And\n> POSIX is very clear that this is an implementation defined behavior.\n> Thanks very much for the response, Herbert.\n>\n> Junio, patch is below. I have no idea how prevalent this issue is within\n> our scripts, but this at least fixes the reported bug.\n\nGaah.  Ok, dash uses \"echo -e\" behaviour by default.\n\nI guess we need to hunt allmost all \"echo\", as I suspect most of\nthem (except the ones we use to do \"echo $SHA1\") have user\nstrings somewhere.\n\nWhat a mess, but that is not your fault nor Herbert's.\n\nThanks.\n"},{"id":"43323","messageId":"7vps4onps0.fsf@assigned-by-dhcp.cox.net","threadId":"8314","inReplyTo":"20070526034236.GA18169@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-26T04:59:43Z","receivedAt":"2007-05-26T04:59:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It turns out that git-commit also shares the same problem under\ndash.\n\n-- >8 --\ngit-commit: use printf \"%s\\n\" instead of echo on user-supplied strings\n\nThis adds a test to verify the earlier fix to git-am by Jeff\nKing, and fixes the same issue in git-commit that is exposed by\nthe new test while at it.\n\nCleverly enough, this commit's log message is a good test case\nat the same time.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n * I suspect we would declare either \"war on echo\" or \"harder push\n   for builtins\" triggered by these.\n\n git-commit.sh           |    8 ++++----\n t/t4014-format-patch.sh |    6 +++---\n 2 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 292cf96..f3f9a35 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -376,12 +376,12 @@ t,)\n \t\t\trm -f \"$TMP_INDEX\"\n \t\tfi || exit\n \n-\t\techo \"$commit_only\" |\n+\t\tprintf \"%s\\n\" \"$commit_only\" |\n \t\tGIT_INDEX_FILE=\"$TMP_INDEX\" \\\n \t\tgit-update-index --add --remove --stdin &&\n \n \t\tsave_index &&\n-\t\techo \"$commit_only\" |\n+\t\tprintf \"%s\\n\" \"$commit_only\" |\n \t\t(\n \t\t\tGIT_INDEX_FILE=\"$NEXT_INDEX\"\n \t\t\texport GIT_INDEX_FILE\n@@ -432,7 +432,7 @@ fi\n \n if test \"$log_message\" != ''\n then\n-\techo \"$log_message\"\n+\tprintf \"%s\\n\" \"$log_message\"\n elif test \"$logfile\" != \"\"\n then\n \tif test \"$logfile\" = -\n@@ -475,7 +475,7 @@ if test -f \"$GIT_DIR/MERGE_HEAD\" && test -z \"$no_edit\"; then\n \techo \"#\"\n \techo \"# It looks like you may be committing a MERGE.\"\n \techo \"# If this is not correct, please remove the file\"\n-\techo \"#\t$GIT_DIR/MERGE_HEAD\"\n+\tprintf \"%s\\n\" \"#\t$GIT_DIR/MERGE_HEAD\"\n \techo \"# and try again\"\n \techo \"#\"\n fi >>\"$GIT_DIR\"/COMMIT_EDITMSG\ndiff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh\nindex 4795872..42aa9e4 100755\n--- a/t/t4014-format-patch.sh\n+++ b/t/t4014-format-patch.sh\n@@ -16,16 +16,16 @@ test_expect_success setup '\n \n \tfor i in 1 2 5 6 A B C 7 8 9 10; do echo \"$i\"; done >file &&\n \tgit update-index file &&\n-\tgit commit -m \"Side change #1\" &&\n+\tgit commit -m \"Side changes #1\" &&\n \n \tfor i in D E F; do echo \"$i\"; done >>file &&\n \tgit update-index file &&\n-\tgit commit -m \"Side change #2\" &&\n+\tgit commit -m \"Side changes #2\" &&\n \tgit tag C2 &&\n \n \tfor i in 5 6 1 2 3 A 4 B C 7 8 9 10 D E F; do echo \"$i\"; done >file &&\n \tgit update-index file &&\n-\tgit commit -m \"Side change #3\" &&\n+\tgit commit -m \"Side changes #3 with \\\\n backslash-n in it.\" &&\n \n \tgit checkout master &&\n \tgit diff-tree -p C2 | git apply --index &&\n"},{"id":"43327","messageId":"20070526060748.GA20715@coredump.intra.peff.net","threadId":"8314","inReplyTo":"7vps4onps0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-26T06:07:48Z","receivedAt":"2007-05-26T06:07:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 25, 2007 at 09:59:43PM -0700, Junio C Hamano wrote:\n\n>  * I suspect we would declare either \"war on echo\" or \"harder push\n>    for builtins\" triggered by these.\n\nCry havoc! More fixes below (just a diff -- maybe we want to aggregate\nthese into a single commit?).\n\nThese are the ones I noticed that use commit messages (which are\nprobably the most likely to use backslash). There are _tons_ of uses for\nheads and filenames. I think we either should stop with commit messages,\nor go all-out and simply remove all uses of echo (because there are\nliterally hundreds otherwise).\n\n> -\t\techo \"$commit_only\" |\n> +\t\tprintf \"%s\\n\" \"$commit_only\" |\n\nIs \"\\n\" portable to all shells (i.e., do you need '\\n')? It works with\nbash and dash, which are by far the most common, but who knows what evil\nlurks in the heart of Sun?\n\n---\ndiff --git a/git-am.sh b/git-am.sh\nindex 543efd0..8b57129 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -18,7 +18,7 @@ stop_here () {\n \n stop_here_user_resolve () {\n     if [ -n \"$resolvemsg\" ]; then\n-\t    echo \"$resolvemsg\"\n+\t    printf '%s\\n' \"$resolvemsg\"\n \t    stop_here $1\n     fi\n     cmdline=$(basename $0)\n@@ -146,7 +146,7 @@ do\n \tgit_apply_opt=\"$git_apply_opt $1\"; shift ;;\n \n \t--resolvemsg=*)\n-\tresolvemsg=$(echo \"$1\" | sed -e \"s/^--resolvemsg=//\"); shift ;;\n+\tresolvemsg=${1#--resolvemsg=}; shift ;;\n \n \t--)\n \tshift; break ;;\ndiff --git a/git-commit.sh b/git-commit.sh\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 44e9b70..981d69d 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -335,7 +335,7 @@ f,*)\n \t\tthen\n \t\t\techo \"Wonderful.\"\n \t\t\tresult_commit=$(\n-\t\t\t\techo \"$merge_msg\" |\n+\t\t\t\tprintf '%s\\n' \"$merge_msg\" |\n \t\t\t\tgit-commit-tree $result_tree -p HEAD -p \"$1\"\n \t\t\t) || exit\n \t\t\tfinish \"$result_commit\" \"In-index merge\"\n@@ -440,7 +440,7 @@ done\n if test '' != \"$result_tree\"\n then\n     parents=$(git-show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n-    result_commit=$(echo \"$merge_msg\" | git-commit-tree $result_tree $parents) || exit\n+    result_commit=$(printf '%s\\n' \"$merge_msg\" | git-commit-tree $result_tree $parents) || exit\n     finish \"$result_commit\" \"Merge made by $wt_strategy.\"\n     dropsave\n     exit 0\n@@ -479,7 +479,7 @@ else\n \tdo\n \t\techo $remote\n \tdone >\"$GIT_DIR/MERGE_HEAD\"\n-\techo \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n+\tprintf '%s\\n' \"$merge_msg\" >\"$GIT_DIR/MERGE_MSG\"\n fi\n \n if test \"$merge_was_ok\" = t\ndiff --git a/git-tag.sh b/git-tag.sh\nindex 4a0a7b6..6f0b7a7 100755\n--- a/git-tag.sh\n+++ b/git-tag.sh\n@@ -126,7 +126,7 @@ if [ \"$annotate\" ]; then\n           echo \"#\" ) > \"$GIT_DIR\"/TAG_EDITMSG\n         ${VISUAL:-${EDITOR:-vi}} \"$GIT_DIR\"/TAG_EDITMSG || exit\n     else\n-        echo \"$message\" >\"$GIT_DIR\"/TAG_EDITMSG\n+        printf '%s\\n' \"$message\" >\"$GIT_DIR\"/TAG_EDITMSG\n     fi\n \n     grep -v '^#' <\"$GIT_DIR\"/TAG_EDITMSG |\n"},{"id":"43328","messageId":"7v3b1knmda.fsf@assigned-by-dhcp.cox.net","threadId":"8314","inReplyTo":"20070526060748.GA20715@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-26T06:13:21Z","receivedAt":"2007-05-26T06:13:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, May 25, 2007 at 09:59:43PM -0700, Junio C Hamano wrote:\n>\n>>  * I suspect we would declare either \"war on echo\" or \"harder push\n>>    for builtins\" triggered by these.\n>\n> Cry havoc! More fixes below (just a diff -- maybe we want to aggregate\n> these into a single commit?).\n>\n> These are the ones I noticed that use commit messages (which are\n> probably the most likely to use backslash). There are _tons_ of uses for\n> heads and filenames. I think we either should stop with commit messages,\n> or go all-out and simply remove all uses of echo (because there are\n> literally hundreds otherwise).\n>\n>> -\t\techo \"$commit_only\" |\n>> +\t\tprintf \"%s\\n\" \"$commit_only\" |\n>\n> Is \"\\n\" portable to all shells (i.e., do you need '\\n')? It works with\n> bash and dash, which are by far the most common, but who knows what evil\n> lurks in the heart of Sun?\n\nGaah, you are right.\n"},{"id":"43329","messageId":"20070526061942.GA5986@gondor.apana.org.au","threadId":"8314","inReplyTo":"20070526060748.GA20715@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2007-05-26T06:19:42Z","receivedAt":"2007-05-26T06:19:42Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"On Sat, May 26, 2007 at 02:07:48AM -0400, Jeff King wrote:\n>\n> > -\t\techo \"$commit_only\" |\n> > +\t\tprintf \"%s\\n\" \"$commit_only\" |\n> \n> Is \"\\n\" portable to all shells (i.e., do you need '\\n')? It works with\n> bash and dash, which are by far the most common, but who knows what evil\n> lurks in the heart of Sun?\n\nYou mean the \"\\n\" in printf? Yes that is specified in POSIX.\nWithout the \"\\n\" printf will act like echo -n (which incidentally\nis forbidden by POSIX).\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>\nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"},{"id":"43330","messageId":"20070526062748.GA21229@coredump.intra.peff.net","threadId":"8314","inReplyTo":"20070526061942.GA5986@gondor.apana.org.au","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-26T06:27:48Z","receivedAt":"2007-05-26T06:27:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 26, 2007 at 04:19:42PM +1000, Herbert Xu wrote:\n\n> > Is \"\\n\" portable to all shells (i.e., do you need '\\n')? It works with\n> > bash and dash, which are by far the most common, but who knows what evil\n> > lurks in the heart of Sun?\n> \n> You mean the \"\\n\" in printf? Yes that is specified in POSIX.\n> Without the \"\\n\" printf will act like echo -n (which incidentally\n> is forbidden by POSIX).\n\nNo, I meant would the shell, while interpolating a double-quoted string\n\"\\n\", always preserve the string and pass the backslash and 'n' to\nprintf?  Clearly \\\\ and \\\" get interpolated, but I don't know the rules\nfor \"unrecognized\" backslash sequences.\n\n-Peff\n"},{"id":"43331","messageId":"20070526073855.GA6395@gondor.apana.org.au","threadId":"8314","inReplyTo":"20070526062748.GA21229@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Herbert Xu","fromEmail":"herbert@gondor.apana.org.au","sentAt":"2007-05-26T07:38:55Z","receivedAt":"2007-05-26T07:38:55Z","isPatch":false,"sender":{"key":"herbert@gondor.apana.org.au","avatar":null},"body":"On Sat, May 26, 2007 at 02:27:48AM -0400, Jeff King wrote:\n> \n> No, I meant would the shell, while interpolating a double-quoted string\n> \"\\n\", always preserve the string and pass the backslash and 'n' to\n> printf?  Clearly \\\\ and \\\" get interpolated, but I don't know the rules\n> for \"unrecognized\" backslash sequences.\n\nYep.  Section 2.2.3 says that the backslash within double quotes will\nonly serve as an escape character for $, `, \", \\ and <newline>.  Of\ncourse, you can always use a single quote instead, i.e.,\n\nprintf '%s\\n' \"$VAR\"\n\nThen there can be no doubt :)\n\nCheers,\n-- \nVisit Openswan at http://www.openswan.org/\nEmail: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>\nHome Page: http://gondor.apana.org.au/~herbert/\nPGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt\n"},{"id":"43332","messageId":"20070526074703.GA2563@coredump.intra.peff.net","threadId":"8314","inReplyTo":"20070526073855.GA6395@gondor.apana.org.au","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-05-26T07:47:04Z","receivedAt":"2007-05-26T07:47:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 26, 2007 at 05:38:55PM +1000, Herbert Xu wrote:\n\n> Yep.  Section 2.2.3 says that the backslash within double quotes will\n> only serve as an escape character for $, `, \", \\ and <newline>.  Of\n> course, you can always use a single quote instead, i.e.,\n> \n> printf '%s\\n' \"$VAR\"\n> \n> Then there can be no doubt :)\n\nRight, I wasn't sure if the single quotes were necessary, but it looks\nlike Junio's version (with doublequotes) is also fine according to\nPOSIX. Thanks again.\n\n-Peff\n"},{"id":"43333","messageId":"7vps4om3gi.fsf@assigned-by-dhcp.cox.net","threadId":"8314","inReplyTo":"20070526060748.GA20715@coredump.intra.peff.net","subject":"Re: Bug: git-rebase goofs up \\n in commit messages","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-26T07:47:09Z","receivedAt":"2007-05-26T07:47:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, May 25, 2007 at 09:59:43PM -0700, Junio C Hamano wrote:\n>\n>>  * I suspect we would declare either \"war on echo\" or \"harder push\n>>    for builtins\" triggered by these.\n>\n> Cry havoc! More fixes below (just a diff -- maybe we want to aggregate\n> these into a single commit?).\n>\n> These are the ones I noticed that use commit messages (which are\n> probably the most likely to use backslash). There are _tons_ of uses for\n> heads and filenames. I think we either should stop with commit messages,\n> or go all-out and simply remove all uses of echo (because there are\n> literally hundreds otherwise).\n\nAt least the ones you did look very sane to me.  Will apply with\nappropriate log message, credit to you.\n\nThanks.\n\nI do not think we need to do all the uses of 'echo'.  Many of\nthem are clearly fixed string we know about, object names we\nparsed out of plumbing output, refnames and refspecs, all of\nwhich should be safe.\n\nOther worrisome ones are pathnames, but (1) I do not think\nanybody is insane enough to have slashed funnies in their\npathname components, (2) half the pathnames we deal with come\nfrom plumbing output which use '/' as path component separator\neven on Windows, (3) users can use forward slash as path\ncomponent separator in their input even on Windows, and (4) even\nthough we try to use -z output from plumbing and read it with -0\ncapable downstream in some of our pipelines, many pure-shell\nscripts read non-z output using shell built-in \"read\" and do not\nunquote c-quoted ones, so they do not work correctly if you have\nHT or LF in your pathnames anyway (notable exception is that\npipelines between git plumbing, e.g. \"ls-files | update-index\n--stdin\", are safe without -z, as the downstream knows how to\nunquote c-quoted paths).\n\nI would expect that by the time we run out of more important\nthings to worry about and start worrying about truly funny\npathnames, we would have rewritten more of the remaining\nPorcelains shell scripts in C, which automatically would make\nthis problem go away.\n"}]}