Re: t6200: avoid path mangling issue on Windows
Johannes Sixt wrote:
Am 21.04.2013 02:05, schrieb Jonathan Nieder:
Junio C Hamano wrote:
But a _real user_ who wants to use a slash there has no way of doing
so.
Doesn't foo=// do that in the msys world? If I am reading
mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass
a true double-slash is foo=///.
That would be totally unexpected.
There is an exception to the path mangling for //unc/paths, if that's
what you mean.
From [1]:
if (path[0] == '/' path[1] == '/')
{
int tidx = 2;
while (spath[tidx] spath[tidx] == '/')
tidx++;
if (strchr (spath[tidx], '/'))
{
retpathcpy (spath);
}
else
{
retpathcpy (spath[1]);
}
return ScrubRetpath (retpath);
}
I haven't tested, since I don't have easy access to a Windows test
setup.
Regards,
Jonathan
[1]
http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/path.cc?content-type=text%2Fplain
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: But a _real user_ who wants to use a slash there has no way of doing so. Doesn't foo=// do that in the msys world? that refers to...? Do you mean: $ value=/; mycmd key=$value breaks msys, but you can say $ value=//; mycmd key=$value instead to pass a value that is a single slash. then that is not a valid workaround; it would work differently between Windows (passes one slash?) and everybody else (passes two slashes). I do not mean to say the '' (empty string) and what you want to say and '' (empty string) concatenated together I suggested in the previous message is a workable (let alone the best) proposition, but if $ value=/; mycmd key=''$value'' worked as a way to temporarily turn off the path mangling, it at least would be a usable workaround that would work the same way between Windows and everybody else. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Junio C Hamano wrote: But a _real user_ who wants to use a slash there has no way of doing so. Doesn't foo=// do that in the msys world? If I am reading mingw/msys/rt/src/winsup/cygwin/path.cc correctly then the way to pass a true double-slash is foo=///. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Johannes Sixt j.s...@viscovery.net writes: Am 4/18/2013 19:05, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org MSYS bash interprets the slash in the argument core.commentchar=/ as root directory and mangles it into a Windows style path. Use a different core.commentchar to dodge the issue. Signed-off-by: Johannes Sixt j...@kdbg.org ... - git -c core.commentchar=/ fmt-merge-msg --log=5 .git/FETCH_HEAD actual + git -c core.commentchar=x fmt-merge-msg --log=5 .git/FETCH_HEAD actual Sigh... Again? Are folks working on Msys bash aware that sometimes the users may want to say key=value on their command line without the value getting molested in any way and giving them some escape hatch would help them? Perhaps they have already decided that it is not feasible after thinking about the issue, in which case I do not have new ideas to offer. What is the issue? And in which way would an escape hatch help us here? When the user passes key=value and value begins with a slash, value may be a path in the filesystem very often, and adjusting it to the local filesystem convention helps Windows users a lot. But there are cases outside that very often when the user wants the value passed literally. There seems to be no way to do so. That is the issue I was wondering. If there is a clean solution to disable path mangling per token, we could cleanly solve it. For example, while making sure that a value that begins with slash in normal cases is still adjusted, i.e. mangling all of the following, xyzzy key=/a/b/c xyzzy key=/a/b/c value=/a/b/c; xyzzy key=$value value=/a/b/c; xyzzy key=$value if bash could be told with a very unnatural and not so hard to type way that the particular value is not to be mangled, e.g. xyzzy key=/a/b/c value=/a/b/c; xyzzy key=$value which a normal bash would interpret as the concatenation of an empty string inside dq, /a/b/c/ (or key=$value) inside dq, and an empty string inside dq, which is the same as /a/b/c (or key=$value) inside dq, it would help the less common case. Nobody would type a string surrounded by two empty strings to be concatenated on purpose (i.e. very unnatural) and typing the same dq four more times than you would normally do is not too much of a hassle (not so hard to type). The problematic case can then be fixed to git -c core.commentchar=/ fmt-merge-msg ... and it will work the same way on and off Windows. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Am 19.04.2013 18:33, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: Am 4/18/2013 19:05, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org MSYS bash interprets the slash in the argument core.commentchar=/ as root directory and mangles it into a Windows style path. Use a different core.commentchar to dodge the issue. Signed-off-by: Johannes Sixt j...@kdbg.org ... - git -c core.commentchar=/ fmt-merge-msg --log=5 .git/FETCH_HEAD actual + git -c core.commentchar=x fmt-merge-msg --log=5 .git/FETCH_HEAD actual Sigh... Again? Are folks working on Msys bash aware that sometimes the users may want to say key=value on their command line without the value getting molested in any way and giving them some escape hatch would help them? Perhaps they have already decided that it is not feasible after thinking about the issue, in which case I do not have new ideas to offer. What is the issue? And in which way would an escape hatch help us here? When the user passes key=value and value begins with a slash, value may be a path in the filesystem very often, and adjusting it to the local filesystem convention helps Windows users a lot. But there are cases outside that very often when the user wants the value passed literally. There seems to be no way to do so. ... if bash could be told with a very unnatural and not so hard to type way that the particular value is not to be mangled, e.g. xyzzy key=/a/b/c I'll not argue whether such a feature would make sense or not, or whether it can be implemented, because it is aimed at the user, but misses one important point: It does in no way help our development process. A patch auther whose first instinct is to write 'foo=/' will never write 'foo=x', let alone 'foo=/'. Someone will have to discover the issue eventually and write a patch to fix it, and someone will have to apply it. I don't think that we can do anything about it. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Johannes Sixt j...@kdbg.org writes: A patch auther whose first instinct is to write 'foo=/' will never write 'foo=x', let alone 'foo=/'. Someone will have to discover the issue eventually and write a patch to fix it, and someone will have to apply it. That is a separate issue. Didn't I say I'll apply it as-is at the very beginning? Our _tests_ can afford to use an unrealistic setting like git -c core.commentchar=x fmt-merge-msg to work it around, because the tests do not _care_ how the final outcome looks like. It only cares what we specified gets used. But a _real user_ who wants to use a slash there has no way of doing so. It is still not realistic, as it is more likely that she would want to use a double-slash, but that would not fit in a commentchar, and she is a lot more likely to have it in the configuration file, but I wouldn't imagine that there are things other than -c var=val that are more commonly given on the command line that share the same pain point as this one. That is what I meant by feels painful to the users and wondered if bash on Windows can be more helpful to them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org MSYS bash interprets the slash in the argument core.commentchar=/ as root directory and mangles it into a Windows style path. Use a different core.commentchar to dodge the issue. Signed-off-by: Johannes Sixt j...@kdbg.org ... - git -c core.commentchar=/ fmt-merge-msg --log=5 .git/FETCH_HEAD actual + git -c core.commentchar=x fmt-merge-msg --log=5 .git/FETCH_HEAD actual Sigh... Again? Are folks working on Msys bash aware that sometimes the users may want to say key=value on their command line without the value getting molested in any way and giving them some escape hatch would help them? Perhaps they have already decided that it is not feasible after thinking about the issue, in which case I do not have new ideas to offer. I'll apply the patch as-is, but this feels really painful to the users. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t6200: avoid path mangling issue on Windows
Am 4/18/2013 19:05, schrieb Junio C Hamano: Johannes Sixt j.s...@viscovery.net writes: From: Johannes Sixt j...@kdbg.org MSYS bash interprets the slash in the argument core.commentchar=/ as root directory and mangles it into a Windows style path. Use a different core.commentchar to dodge the issue. Signed-off-by: Johannes Sixt j...@kdbg.org ... -git -c core.commentchar=/ fmt-merge-msg --log=5 .git/FETCH_HEAD actual +git -c core.commentchar=x fmt-merge-msg --log=5 .git/FETCH_HEAD actual Sigh... Again? Are folks working on Msys bash aware that sometimes the users may want to say key=value on their command line without the value getting molested in any way and giving them some escape hatch would help them? Perhaps they have already decided that it is not feasible after thinking about the issue, in which case I do not have new ideas to offer. What is the issue? And in which way would an escape hatch help us here? We would have to apply a patch anyway after a glitch like this shows up, because disabling path mangling whole-sale (if there were a method -- there is none currently) is a no-go in the context of our test suite, let a lone in our scripted tool set. When foo=/ appears on the command line, the most obvious interpretation of the slash for a program without mind-reading mode is that it is an absolute path, and then path mangling must happen (if and only if the invoked program is a non-MSYS program such as git). I'll apply the patch as-is, but this feels really painful to the users. No, generally, path mangling is a service for the user. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
