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
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:
- Because `bash` is a Bourne-style shell, the path used to invoke
it appears as `$0` in some circumstances, such as when it is used
to run a command with `-c` with no arguments after its operand.
Ideally it will never be assumed to use `/` separators, and
ideally it will never be used in a way that treats backslashes
appearing in it as escape characters. But in practice this is
sometimes hard to avoid.
- The prefix, which is part of the output of `git --exec-path`,
already uses `/` separatros, except in the unusual case that it
overridden to a value containing `\` by setting the
`GIT_EXEC_PATH` environment. So we are usually mixing `/` and `\`
separators if we append with `\`, and usually avoiding mixing
them if we append with `/`. Mixing directory separators is
permitted, but the resulting paths are often more confusing when
they appear in messages, and more broadly combine the
disadvantages of each form.
This also refactors for clarity, and adds new tests related to the
change.
0 commit comments