Open MGraefe opened 2 years ago
Does opening Terminal from the explorer address bar repro the same behavior? (wt -d .
to open up in the same CWD)
What do the environment variables look like when:
I know that's a lot, but I'm just looking for anything that's different here, maybe some smoking gun that some env var didn't propogate
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
Hi, sorry for the delayed feedback.
wt -d .
into the explorer address bar shows the correct behavior, tilde expansion works.Environment variables seem okay, even in the case where tilde expansion is not working:
BOB@MYPC MINGW64 /c
$ cd ~
bash: cd: /c/%HOMEDRIVE%%HOMEPATH%: No such file or directory
BOB@MYPC MINGW64 /c
$ echo $HOMEDRIVE $HOMEPATH
C: \Users\Bob
I am not sure what other environment variables you're interested in. The problem seems to be that bash gets fed the unexpanded cmd-like %HOMEDRIVE%
and %HOMEPATH%
paths.
Alright shoot. I can't repro this on
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
git version 2.33.0.vfs.0.0
I wonder if this is a recent regression in git bash. I honestly don't even know the right place to look there.
Like, why is ~
evaluating without expanding %HOMEDRIVE%%HOMEPATH%
. That's weird, and that doesn't seem like something that the Terminal would affect.
Does wt -d c:\windows
from the Run dialog (win+r) work as expected? I'm totally at a loss here, sorry 😕
Hi, thanks for caring.
I did printenv
in both scenarios (broken and working tilde expansion) and diff'ed the result. Seems like a couple of environment variables are screwed up, e.g:
-ORIGINAL_PATH=/mingw64/bin:/usr/bin:%HOMEDRIVE%%HOMEPATH%/bin:(other entries)
+ORIGINAL_PATH=/mingw64/bin:/usr/bin:/c/Users/Bob/bin:/c/Program Files/WindowsApps/Microsoft.WindowsTerminal_1.14.2281.0_x64__8wekyb3d8bbwe:(other entries)
and probably most important
-HOME=/c/%HOMEDRIVE%%HOMEPATH%
+HOME=/c/Users/Bob
also the PATH contains a couple of %HOMEDRIVE%%HOMEPATH%
entries in places where HOME probably gets inserted.
I am not sure what's going on with the env vars when starting from the explorer right-click menu, but something is fairly broken.
Weird. That's a bit like #7204, but it's almost like HOMEDRIVE
and HOMEPATH
aren't getting passed s.t. mingw can evaluate them. I wonder if it is because the package dir is getting prepended to the path. I'll leave this open as something in the related web of env var issues. Thanks!
Ok, some new findings: I had the environment variable HOME
defined as C:\Users\Bob
in my normal Windows environment variables user settings. Simply removing that variable makes the tilde expansion for "Open in Terminal" work. I am not sure why I set this environment variable (or which program set it), it's not standard on Windows. Hard to tell when your full-time development machine is getting a bit older...
So most likely Git Bash (or its environment wrapper) has some problems assembling a unix-style HOME
path if there's already a HOME
environment variable.
However, I am still not sure who is at fault here since everything works fine when I start Windows Terminal regulary. What would be the differences between doing wt -d .
in the explorer address bar and doing the right click thingy anyway?!
I am not really sure if this is a problem of the git bash or Windows Terminal, but here we go:
This profile is selected as my default, i.e.
"defaultProfile": "{2ece5bfe-50ed-5f3a-ab87-5cd4baafed2b}",
is set.~
and things likecd ~
work as well. Everything behaves as expected.cd ~
produces the errorbash: cd: /%HOMEDRIVE%%HOMEPATH%: No such file or directory
and I can't use~
in any command really.Git bash here
from the explorer context menu opens a shell in whichcd ~
works without problems.Versions: