{"thread":{"id":"33419","subject":"[PATCH 1/2] fmt-merge-msg: respect core.commentchar in people credits","startedAt":"2013-04-07T15:25:43Z","lastAt":"2013-04-21T07:12:12Z","messageCount":12,"participants":["Ralf Thielow","Johannes Sixt","Junio C Hamano","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"213413","messageId":"1365348344-1648-1-git-send-email-ralf.thielow@gmail.com","threadId":"33419","inReplyTo":null,"subject":"[PATCH 1/2] fmt-merge-msg: respect core.commentchar in people credits","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-04-07T15:25:43Z","receivedAt":"2013-04-07T15:25:43Z","isPatch":true,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Commit eff80a9 (Allow custom \"comment char\") introduced a custom\ncomment character for commit messages but forgot to use it in\npeople credits which can be a part of a commit message.\n\nWith this commit, the custom comment character is also used\nin people credits.\n\nSigned-off-by: Ralf Thielow \n---\n builtin/fmt-merge-msg.c | 6 +++---\n t/t6200-fmt-merge-msg.sh | 18 ++++++++++++++++++\n 2 files changed, 21 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c\nindex 265a925..88df93a 100644\n--- a/builtin/fmt-merge-msg.c\n+++ b/builtin/fmt-merge-msg.c\n@@ -287,10 +287,10 @@ static void credit_people(struct strbuf *out,\n \tconst char *me;\n \n \tif (kind == 'a') {\n-\t\tlabel = \"\\n# By \";\n+\t\tlabel = \"By\";\n \t\tme = git_author_info(IDENT_NO_DATE);\n \t} else {\n-\t\tlabel = \"\\n# Via \";\n+\t\tlabel = \"Via\";\n \t\tme = git_committer_info(IDENT_NO_DATE);\n \t}\n \n@@ -300,7 +300,7 @@ static void credit_people(struct strbuf *out,\n \t (me = skip_prefix(me, them->items->string)) != NULL &&\n \t skip_prefix(me, \" <\")))\n \t\treturn;\n-\tstrbuf_addstr(out, label);\n+\tstrbuf_addf(out, \"\\n%c %s \", comment_line_char, label);\n \tadd_people_count(out, them);\n }\n \ndiff --git a/t/t6200-fmt-merge-msg.sh b/t/t6200-fmt-merge-msg.sh\nindex 992c2a0..84e10fd 100755\n--- a/t/t6200-fmt-merge-msg.sh\n+++ b/t/t6200-fmt-merge-msg.sh\n@@ -180,6 +180,24 @@ test_expect_success 'merge.log=5 shows all 5 commits' '\n \ttest_cmp expected actual\n '\n \n+test_expect_success '--log=5 with custom comment character' '\n+\tcat >expected <<-EOF &&\n+\tMerge branch ${apos}left${apos}\n+\n+\t/ By Another Author (3) and A U Thor (2)\n+\t/ Via Another Committer\n+\t* left:\n+\t Left #5\n+\t Left #4\n+\t Left #3\n+\t Common #2\n+\t Common #1\n+\tEOF\n+\n+\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_expect_success 'merge.log=0 disables shortlog' '\n \techo \"Merge branch ${apos}left${apos}\" >expected\n \tgit -c merge.log=0 fmt-merge-msg <.git/FETCH_HEAD >actual &&\n-- \n1.8.2.470.g21ccebe\n"},{"id":"213414","messageId":"1365348344-1648-2-git-send-email-ralf.thielow@gmail.com","threadId":"33419","inReplyTo":"1365348344-1648-1-git-send-email-ralf.thielow@gmail.com","subject":"[PATCH 2/2] fmt-merge-msg: use core.commentchar in tag signatures completely","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-04-07T15:25:44Z","receivedAt":"2013-04-07T15:25:44Z","isPatch":true,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Commit eff80a9 (Allow custom \"comment char\") introduced a custom\ncomment character for commit messages but didn't use it completely\nin the tag signature part.\n\nThis commit fixes that.\n\nSigned-off-by: Ralf Thielow \n---\n builtin/fmt-merge-msg.c | 12 ++++++++----\n 1 file changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c\nindex 88df93a..1c04070 100644\n--- a/builtin/fmt-merge-msg.c\n+++ b/builtin/fmt-merge-msg.c\n@@ -503,14 +503,18 @@ static void fmt_merge_msg_sigs(struct strbuf *out)\n \t\t} else {\n \t\t\tif (tag_number == 2) {\n \t\t\t\tstruct strbuf tagline = STRBUF_INIT;\n-\t\t\t\tstrbuf_addf(&tagline, \"\\n# %s\\n\",\n-\t\t\t\t\t origins.items[first_tag].string);\n+\t\t\t\tstrbuf_addch(&tagline, '\\n');\n+\t\t\t\tstrbuf_add_commented_lines(&tagline,\n+\t\t\t\t\t\torigins.items[first_tag].string,\n+\t\t\t\t\t\tstrlen(origins.items[first_tag].string));\n \t\t\t\tstrbuf_insert(&tagbuf, 0, tagline.buf,\n \t\t\t\t\t tagline.len);\n \t\t\t\tstrbuf_release(&tagline);\n \t\t\t}\n-\t\t\tstrbuf_addf(&tagbuf, \"\\n# %s\\n\",\n-\t\t\t\t origins.items[i].string);\n+\t\t\tstrbuf_addch(&tagbuf, '\\n');\n+\t\t\tstrbuf_add_commented_lines(&tagbuf,\n+\t\t\t\t\torigins.items[i].string,\n+\t\t\t\t\tstrlen(origins.items[i].string));\n \t\t\tfmt_tag_signature(&tagbuf, &sig, buf, len);\n \t\t}\n \t\tstrbuf_release(&sig);\n-- \n1.8.2.470.g21ccebe\n"},{"id":"214682","messageId":"516F95D1.5070209@viscovery.net","threadId":"33419","inReplyTo":"1365348344-1648-2-git-send-email-ralf.thielow@gmail.com","subject":"t6200: avoid path mangling issue on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-04-18T06:42:25Z","receivedAt":"2013-04-18T06:42:25Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nMSYS bash interprets the slash in the argument core.commentchar=\"/\"\nas root directory and mangles it into a Windows style path. Use a\ndifferent core.commentchar to dodge the issue.\n\nSigned-off-by: Johannes Sixt \n---\n t/t6200-fmt-merge-msg.sh | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/t/t6200-fmt-merge-msg.sh b/t/t6200-fmt-merge-msg.sh\nindex e7e945d..54b5744 100755\n--- a/t/t6200-fmt-merge-msg.sh\n+++ b/t/t6200-fmt-merge-msg.sh\n@@ -179,8 +179,8 @@ test_expect_success '--log=5 with custom comment character' '\n \tcat >expected <<-EOF &&\n \tMerge branch ${apos}left${apos}\n \n-\t/ By Another Author (3) and A U Thor (2)\n-\t/ Via Another Committer\n+\tx By Another Author (3) and A U Thor (2)\n+\tx Via Another Committer\n \t* left:\n \t Left #5\n \t Left #4\n@@ -189,7 +189,7 @@ test_expect_success '--log=5 with custom comment character' '\n \t Common #1\n \tEOF\n \n-\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n+\tgit -c core.commentchar=\"x\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n \ttest_cmp expected actual\n '\n \n-- \n1.8.2.1.1678.gf713add\n"},{"id":"214735","messageId":"7v38un93br.fsf@alter.siamese.dyndns.org","threadId":"33419","inReplyTo":"516F95D1.5070209@viscovery.net","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-18T17:05:44Z","receivedAt":"2013-04-18T17:05:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> From: Johannes Sixt \n>\n> MSYS bash interprets the slash in the argument core.commentchar=\"/\"\n> as root directory and mangles it into a Windows style path. Use a\n> different core.commentchar to dodge the issue.\n>\n> Signed-off-by: Johannes Sixt \n> ...\n> -\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n> +\tgit -c core.commentchar=\"x\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n\nSigh... Again?\n\nAre folks working on Msys bash aware that sometimes the users may\nwant to say key=value on their command line without the value\ngetting molested in any way and giving them some escape hatch would\nhelp them? Perhaps they have already decided that it is not\nfeasible after thinking about the issue, in which case I do not have\nnew ideas to offer.\n\nI'll apply the patch as-is, but this feels really painful to the\nusers.\n\nThanks.\n"},{"id":"214807","messageId":"5170DA96.9000300@viscovery.net","threadId":"33419","inReplyTo":"7v38un93br.fsf@alter.siamese.dyndns.org","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-04-19T05:48:06Z","receivedAt":"2013-04-19T05:48:06Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 4/18/2013 19:05, schrieb Junio C Hamano:\n> Johannes Sixt writes:\n> \n>> From: Johannes Sixt \n>>\n>> MSYS bash interprets the slash in the argument core.commentchar=\"/\"\n>> as root directory and mangles it into a Windows style path. Use a\n>> different core.commentchar to dodge the issue.\n>>\n>> Signed-off-by: Johannes Sixt \n>> ...\n>> -\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n>> +\tgit -c core.commentchar=\"x\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n> \n> Sigh... Again?\n> \n> Are folks working on Msys bash aware that sometimes the users may\n> want to say key=value on their command line without the value\n> getting molested in any way and giving them some escape hatch would\n> help them? Perhaps they have already decided that it is not\n> feasible after thinking about the issue, in which case I do not have\n> new ideas to offer.\n\nWhat is \"the issue\"? And in which way would an escape hatch help us here?\nWe would have to apply a patch anyway after a glitch like this shows up,\nbecause disabling path mangling whole-sale (if there were a method --\nthere is none currently) is a no-go in the context of our test suite, let\na lone in our scripted tool set.\n\nWhen \"foo=/\" appears on the command line, the most obvious interpretation\nof the slash for a program without mind-reading mode is that it is an\nabsolute path, and then path mangling must happen (if and only if the\ninvoked program is a non-MSYS program such as git).\n\n> I'll apply the patch as-is, but this feels really painful to the\n> users.\n\nNo, generally, path mangling is a service for the user.\n\n-- Hannes\n"},{"id":"214837","messageId":"7vr4i632fp.fsf@alter.siamese.dyndns.org","threadId":"33419","inReplyTo":"5170DA96.9000300@viscovery.net","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-19T16:33:46Z","receivedAt":"2013-04-19T16:33:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 4/18/2013 19:05, schrieb Junio C Hamano:\n>> Johannes Sixt writes:\n>> \n>>> From: Johannes Sixt \n>>>\n>>> MSYS bash interprets the slash in the argument core.commentchar=\"/\"\n>>> as root directory and mangles it into a Windows style path. Use a\n>>> different core.commentchar to dodge the issue.\n>>>\n>>> Signed-off-by: Johannes Sixt \n>>> ...\n>>> -\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n>>> +\tgit -c core.commentchar=\"x\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n>> \n>> Sigh... Again?\n>> \n>> Are folks working on Msys bash aware that sometimes the users may\n>> want to say key=value on their command line without the value\n>> getting molested in any way and giving them some escape hatch would\n>> help them? Perhaps they have already decided that it is not\n>> feasible after thinking about the issue, in which case I do not have\n>> new ideas to offer.\n>\n> What is \"the issue\"? And in which way would an escape hatch help us here?\n\nWhen the user passes key=value and value begins with a slash, value\nmay be a path in the filesystem very often, and adjusting it to the\nlocal filesystem convention helps Windows users a lot.\n\nBut there are cases outside that very often when the user wants the\nvalue passed literally. There seems to be no way to do so.\n\nThat is the issue I was wondering. If there is a clean solution to\ndisable path mangling per token, we could cleanly solve it.\n\nFor example, while making sure that a value that begins with slash\nin normal cases is still adjusted, i.e. mangling all of the\nfollowing,\n\n\txyzzy key=/a/b/c\n xyzzy key=\"/a/b/c\"\n value=/a/b/c; xyzzy key=\"$value\"\n value=/a/b/c; xyzzy \"key=$value\"\n\n\nif bash could be told with a very unnatural and not so hard to type\nway that the particular value is not to be mangled, e.g.\n\n\txyzzy key=\"\"\"/a/b/c\"\"\"\n value=/a/b/c; xyzzy \"\"\"key=$value\"\"\"\n\nwhich a normal bash would interpret as the concatenation of an empty\nstring inside dq, /a/b/c/ (or key=$value) inside dq, and an empty\nstring inside dq, which is the same as /a/b/c (or key=$value) inside\ndq, it would help the less common case. Nobody would type a string\nsurrounded by two empty strings to be concatenated on purpose\n(i.e. very unnatural) and typing the same dq four more times than\nyou would normally do is not too much of a hassle (not so hard to\ntype). The problematic case can then be fixed to\n\n\tgit -c core.commentchar=\"\"\"/\"\"\" fmt-merge-msg ...\n\nand it will work the same way on and off Windows.\n"},{"id":"214880","messageId":"51719F18.3020508@kdbg.org","threadId":"33419","inReplyTo":"7vr4i632fp.fsf@alter.siamese.dyndns.org","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2013-04-19T19:46:32Z","receivedAt":"2013-04-19T19:46:32Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 19.04.2013 18:33, schrieb Junio C Hamano:\n> Johannes Sixt writes:\n> \n>> Am 4/18/2013 19:05, schrieb Junio C Hamano:\n>>> Johannes Sixt writes:\n>>>\n>>>> From: Johannes Sixt \n>>>>\n>>>> MSYS bash interprets the slash in the argument core.commentchar=\"/\"\n>>>> as root directory and mangles it into a Windows style path. Use a\n>>>> different core.commentchar to dodge the issue.\n>>>>\n>>>> Signed-off-by: Johannes Sixt \n>>>> ...\n>>>> -\tgit -c core.commentchar=\"/\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n>>>> +\tgit -c core.commentchar=\"x\" fmt-merge-msg --log=5 <.git/FETCH_HEAD >actual &&\n>>>\n>>> Sigh... Again?\n>>>\n>>> Are folks working on Msys bash aware that sometimes the users may\n>>> want to say key=value on their command line without the value\n>>> getting molested in any way and giving them some escape hatch would\n>>> help them? Perhaps they have already decided that it is not\n>>> feasible after thinking about the issue, in which case I do not have\n>>> new ideas to offer.\n>>\n>> What is \"the issue\"? And in which way would an escape hatch help us here?\n> \n> When the user passes key=value and value begins with a slash, value\n> may be a path in the filesystem very often, and adjusting it to the\n> local filesystem convention helps Windows users a lot.\n> \n> But there are cases outside that very often when the user wants the\n> value passed literally. There seems to be no way to do so.\n> ...\n> if bash could be told with a very unnatural and not so hard to type\n> way that the particular value is not to be mangled, e.g.\n> \n> \txyzzy key=\"\"\"/a/b/c\"\"\"\n\nI'll not argue whether such a feature would make sense or not, or\nwhether it can be implemented, because it is aimed at the user, but\nmisses one important point: It does in no way help our development process.\n\nA patch auther whose first instinct is to write 'foo=/' will never write\n'foo=x', let alone 'foo=\"\"\"/\"\"\"'. Someone will have to discover the\nissue eventually and write a patch to fix it, and someone will have to\napply it.\n\nI don't think that we can do anything about it.\n\n-- Hannes\n"},{"id":"214889","messageId":"7va9ouz04y.fsf@alter.siamese.dyndns.org","threadId":"33419","inReplyTo":"51719F18.3020508@kdbg.org","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-19T21:22:21Z","receivedAt":"2013-04-19T21:22:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> A patch auther whose first instinct is to write 'foo=/' will never write\n> 'foo=x', let alone 'foo=\"\"\"/\"\"\"'. Someone will have to discover the\n> issue eventually and write a patch to fix it, and someone will have to\n> apply it.\n\nThat is a separate issue. Didn't I say I'll apply it as-is at the\nvery beginning?\n\nOur _tests_ can afford to use an unrealistic setting like\n\n git -c core.commentchar=\"x\" fmt-merge-msg\n\nto work it around, because the tests do not _care_ how the final\noutcome looks like. It only cares what we specified gets used.\n\nBut a _real user_ who wants to use a slash there has no way of doing\nso. It is still not realistic, as it is more likely that she would\nwant to use a double-slash, but that would not fit in a commentchar,\nand she is a lot more likely to have it in the configuration file,\nbut I wouldn't imagine that there are things other than \"-c var=val\"\nthat are more commonly given on the command line that share the same\npain point as this one.\n\nThat is what I meant by \"feels painful to the users\" and wondered if\nbash on Windows can be more helpful to them.\n"},{"id":"214950","messageId":"20130421000522.GB10043@elie.Belkin","threadId":"33419","inReplyTo":"7va9ouz04y.fsf@alter.siamese.dyndns.org","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-21T00:05:22Z","receivedAt":"2013-04-21T00:05:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> But a _real user_ who wants to use a slash there has no way of doing\n> so.\n\nDoesn't foo=// do that in the msys world? If I am reading\nmingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass\na true double-slash is foo=///.\n\nJonathan\n"},{"id":"214961","messageId":"517385A6.8020908@kdbg.org","threadId":"33419","inReplyTo":"20130421000522.GB10043@elie.Belkin","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2013-04-21T06:22:30Z","receivedAt":"2013-04-21T06:22:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 21.04.2013 02:05, schrieb Jonathan Nieder:\n> Junio C Hamano wrote:\n> \n>> But a _real user_ who wants to use a slash there has no way of doing\n>> so.\n> \n> Doesn't foo=// do that in the msys world? If I am reading\n> mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass\n> a true double-slash is foo=///.\n\nThat would be totally unexpected.\n\n-- Hannes\n"},{"id":"214962","messageId":"20130421063550.GC10429@elie.Belkin","threadId":"33419","inReplyTo":"517385A6.8020908@kdbg.org","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-04-21T06:35:50Z","receivedAt":"2013-04-21T06:35:50Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Johannes Sixt wrote:\n> Am 21.04.2013 02:05, schrieb Jonathan Nieder:\n>> Junio C Hamano wrote:\n\n>>> But a _real user_ who wants to use a slash there has no way of doing\n>>> so.\n>>\n>> Doesn't foo=// do that in the msys world? If I am reading\n>> mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass\n>> a true double-slash is foo=///.\n>\n> That would be totally unexpected.\n\nThere is an exception to the path mangling for //unc/paths, if that's\nwhat you mean.\n\n>From [1]:\n\n if (path[0] == '/' && path[1] == '/')\n {\n int tidx = 2;\n while (spath[tidx] && spath[tidx] == '/')\n\t tidx++;\n if (strchr (&spath[tidx], '/'))\n\t{\n\t retpathcpy (spath);\n\t}\n else\n\t{\n\t retpathcpy (&spath[1]);\n\t}\n return ScrubRetpath (retpath);\n }\n\nI haven't tested, since I don't have easy access to a Windows test\nsetup.\n\nRegards,\nJonathan\n\n[1] http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/path.cc?content-type=text%2Fplain\n"},{"id":"214967","messageId":"7vli8cwe5v.fsf@alter.siamese.dyndns.org","threadId":"33419","inReplyTo":"20130421000522.GB10043@elie.Belkin","subject":"Re: t6200: avoid path mangling issue on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-21T07:12:12Z","receivedAt":"2013-04-21T07:12:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> But a _real user_ who wants to use a slash there has no way of doing\n>> so.\n>\n> Doesn't foo=// do that in the msys world?\n\n\"that\" refers to...? Do you mean:\n\n $ value=/; mycmd key=\"$value\"\n\n breaks msys, but you can say\n\n $ value=//; mycmd key=\"$value\"\n\n instead to pass a value that is a single slash.\n\nthen that is not a valid workaround; it would work differently\nbetween Windows (passes one slash?) and everybody else (passes two\nslashes).\n\nI do not mean to say the \"'' (empty string) and what you want to say\nand '' (empty string) concatenated together\" I suggested in the\nprevious message is a workable (let alone the best) proposition, but\nif\n\n $ value=/; mycmd key=''\"$value\"''\n\nworked as a way to temporarily turn off the path mangling, it at\nleast would be a usable workaround that would work the same way\nbetween Windows and everybody else.\n"}]}