Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Tue, 21 Jun 2016, Junio C Hamano wrote: > >> I said $PATH because --exec-path does not care what you do with >> %PATH% but it deeply cares that its output is usable in $PATH. > > The really, really, really important part to keep in mind is that there is > no $PATH on Windows. I think I know that well enough; please sanity check. My understanding is: * Your (emulated) getenv(3) reads %PATH% which may look like "c:\a\b;c:\c\d", i.e. Windows style. * Your argv_exec_path also looks like "c:\e\f", i.e. Windows style. * Your setup_path() would yield "c:\e\f;c:\a\b;c:\c\d" because it concatenates the above two with PATH_SEP, i.e. Windows style, and your setenv(3) will set that to %PATH%. * After all that happens, your run_command(), execv_git_cmd(), etc. would honor that %PATH%. * In all of the above, a back-slash can be (and may indeed be) a forward-slash, as library functions and system calls are prepared to take both since the good old DOS days. I.e. "c:\a\b" can be "c:/a/b". It cannot be "/c/a/b", however. * When bash gets spawned (perhaps because a hook is written in that language, perhaps because child_process.use_shell is set when executing an alias "!cmd", running a pager, or running an editor), the value of %PATH% derived by the above sequence is not exposed as $PATH. There is the "rewrite leading C: with /C/" outside us (i.e. in bash). And that is why I suggested to keep that "internal paths are in platform native format" and apply the same conversion as what bash does immediately before the returned value from git_exec_path() is fed to puts(). That way, "$PATH" (not %PATH%) can be modified with "$(git --exec-path)" in scripts the same way on all the platforms and you do not have to break people's hooks. Having said that, I realize that I missed one huge thing to take into consideration. I assume that you have been shipping Git for Windows with this "'git --exec-path' gives c:\a\b, not /c/a/b" feature for a long time, so existing Windows users will be broken if we "fix" this (which would allow them to use shell scripts their friends use on other platforms without modification). So from that point alone, "PATH=$(git --exec-path):$PATH in shell should work on any platform and "git --exec-path" should be fixed" would not fly. This simply is too late to fix. The patch under discussion is the only door left for that test, and a similar trickery is needed for any end-user scripts used for hooks and aliases that use 'git --exec-path', if they ever want to be cross-platform. So let's take that "if Windows do this" change to t2300 as-is. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html