mise does not operate well under GitBash on Windows

[jdx]

Discussed in #3961

^{Originally posted by zartc January 6, 2025}
As a user of GitBash (which comes with Git for Windows), I installed the 2025.1.0 Windows-x64 (ef6936a 2025-01-01).
The program works fine, but it produces paths that are incompatible with GitBash. Any command that updates the PATH variable (including eval $(mise activate bash)) corrupts the GitBash terminal session, rendering it unusable because GitBash cannot find any commands anymore due to the corrupted PATH variable.

The problem:

mise outputs paths in Windows format: C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\local\bin;C:\Program Files\Git\usr\bin using the C: prefix, the \ directory separator, and the ; path separator. However, GitBash expects paths to be in Linux format: using /c/ prefix, / directory separator, and : path separator.

One element of solution:

When running under GitBash ($OSTYPE == "msys"), paths generated by mise should be in Linux format using the / and : separators. In addition, paths pointing to directories inside the GitBash installation directory should be without the C:\Program Files\Git prefix, so that they are seen as absolute paths inside the Linux VFS. For example, C:\Program Files\Git\mingw64\bin => /mingw64/bin, C:\Program Files\Git\usr\bin => /usr/bin.

[david-sharer]

Also a user of gitbash.
I use primarily use gitbash within a VSCode shell.
Installed mise using winget.

Was surprised to find that the instructions for Windows activation only offered powershell, and neither set of instructions for bash worked for my system (with the same "corrupting the terminal" behavior).

I am also having difficulty getting mise en to work in git bash (suggested in the PR comments).
Tho %localappdata%/mise/shims is in my path, and appears to maybe work initially, it looks like it gets stripped from PATH after running mise en? actually it's replaced by the specific package's defined path, but it's not high enough on the PATH list to take over?

Perhaps I have done it wrong, but the conclusion seems to be that this will not work well for my setup.
Bummer, since it looked pretty useful.

---

I'll close this out with some logs of behavior I'm seeing:

# Following the Getting Started guide, skipping the Activate mise step
$ mise use --global node@22
mise WARN  gpg not found, skipping verification
mise [email protected] ✓ installed
mise C:\Users\me\.config\mise\config.toml tools: [email protected]

$ mise exec -- node -v
v20.10.0
# pretty weird, since the test I did moments prior worked... maybe it was somehow in a `mise en` context?

$ node --version
v20.10.0

$ which node
/c/Program Files/nodejs/node

# checking this just because the PR mentioned it
$ node.cmd --version
v20.10.0

$ which node.cmd
which: no node.cmd in (
<snip>
:/c/Program Files/nodejs:/cmd:
<snip>
:/c/Users/me/AppData/Local/mise/shims:
<snip>)

$ ls /c/Users/me/AppData/Local/mise/shims
<snip>  node.cmd  <snip>

# Attempting `mise en` on suggestion from the PR
$ mise en . -s bash

$ mise exec -- node -v
v22.13.1

$ node -v
v20.10.0

$ which node
/c/Program Files/nodejs/node

# checking this just because the PR mentioned it
$ node.cmd -v
bash: node.cmd: command not found

$ which node.cmd
which: no node.cmd in (
<snip>
:/c/Program Files/nodejs:
<snip>
:/c/Users/me/AppData/Local/mise/installs/node/22.13.1:
<snip>)
# shims seems to be gone, but now we have the actual node install?

$ ls /c/Users/me/AppData/Local/mise/installs/node/22.13.1
<snip> node.exe  <snip>
# ... interesting ...

# Same as previous, but I moved the `%LocalAppData%\mise\shims` PATH entry to the top of the list
$ node -v
v20.10.0

$ node.cmd -v
v20.10.0

$ mise exec -- node -v
v20.10.0

$ mise en . -s bash

$ node -v
v20.10.0

$ mise exec -- node -v
v22.13.1

$ node.cmd -v
bash: node.cmd: command not found

$ which node
/c/Program Files/nodejs/node

$ which node.cmd
which: no node.cmd in (
<snip>
:/c/Program Files/nodejs:/cmd:
<snip>
:/c/Users/me/AppData/Local/mise/installs/node/22.13.1:
<snip>)
# it seems like it's closer to the top now, but still not early enough?

# forcing it to the top manually...
$ export PATH="/c/Users/me/AppData/Local/mise/installs/node/22.13.1:$PATH"

$ which node
/c/Users/me/AppData/Local/mise/installs/node/22.13.1/node

$ node -v
v22.13.1
# success?

[david-sharer]

I have noticed another unusual behavior relating to mise en . -s bash
(Operating under VSCode > Git Bash > mise en . -s bash)

If you press Ctrl-C within the context, it seems to "double exit" and the terminal input enters a flakey state.
It also seems to start producing "bonus" newlines with every command set?
I am not sure what could cause this. I have never seen this before.

# Example logs. But, unlike above, I left the (slightly modified) prompt lines in,
# so you can see the fullness of the "double exit" behavior
#
# The full input was:
# mise en . -s bash<enter>
# echo "hello world"<enter>
# echo "goodbye world"<ctrl+c>
# 123456789<ctrl+c>
# <ctrl+c>
me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ mise en . -s bash

me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ echo "hello world"
hello world

me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ echo "goodbye world"^C


me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ 
me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ 34569^C    # this was supposed to be 123456789, quickly done on a numpad



me@pc MINGW64 /c/_dev/somewhere (some-branch)
$ ^C



me@pc MINGW64 /c/_dev/somewhere (some-branch)
$