You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Prefer / over \ in bash.exe path (for fixtures)
Starting in GitoxideLabs#1712, `gix-testtools` looks for `bash.exe` on Windows
in one of its common locations as provided by Git for Windows, by
taking the path given by `git --exec-path`, going up by three
components, and going down to `bin/bash.exe` under that. But the
`bin` and `bash.exe` components were appended in a way that used
`\` directory separators.
Ordinarily, that would be ideal, since `\` is the primary directory
separator on Windows. However, in this case, appending with `\`
produces a path that is harder to read (especially in diagostic
messages), and that may cause problems if it is processed by a
shell or in a way that is intended to operate similarly to shell
processing of `\`.
A path that does not explicitly prefer `/` but instead uses
`PathBuf::push` will have `\` in front of the new components, but
will still usually have `/` in front of the old components. This is
because, aside from the unusual case that the `GIT_EXEC_PATH`
environment vairable is set explicitly and its value uses all `\`
separators, the output of `git --exec-path`, which we use to find
where `git` installed on Windows, uses `/` separators.
The effect of this change seems to be fairly minor, with existing
test fixtures having worked before it was done. This is partly
because, on Windows, the value of `argv[0]` that the shell
actually sees -- and that populates `$0` when no script name is
available, as happens in `bash -c '...'` with no subsequent
arguments -- is translated by an MSYS DLL such as `msys-2.0.dll`
(or, for Cygwin, `cygwin1.dll`) into a Unix-style path meaningful
to the shell.
This also refactors for clarity, and adds new tests related to the
change.
0 commit comments