Biswa96
commented
4 years ago If VSCode is the only reason then you can use aliases in shell rc file. As example, alias vscode=/c/path/to/vscode.exe.
Open Celeborn2BeAlive opened 4 years ago
Biswa96
commented
4 years ago If VSCode is the only reason then you can use aliases in shell rc file. As example, alias vscode=/c/path/to/vscode.exe.
Celeborn2BeAlive
commented
4 years ago If VSCode is the only reason then you can use aliases in shell rc file. As example,
alias vscode=/c/path/to/vscode.exe.
I may have been unclear, my issue is not that VS code cannot be found in my PATH, it can (I just run "code" and vs code starts).
The issue is in the integrated terminal of VS code, which is itself running msys2.
What I run is actually cmder -> msys2 -> "code ." (to open VS code in my current working dir) -> msys2 (inside VS code integrated terminal).
In the first msys2, if I type echo $PATH, I can see my windows PATH which have been correctly converted (all "\" are now "/", and C: or D: is replaced with /c/ or /d/), so everything is fine. I can run git, cmake, code, etc, perfect.
But in the second msys2, the one that run inside VS code, if I type echo $PATH I get my windows PATH (so it means MSYS2_PATH_TYPE=inherit is also working in this instance of msys2), but not converted, all paths are back to their windows version with "\" separator and C:, D:, etc. So in this msys2 I cannot run git, cmake, etc (and no I don't want to write an alias for all my binaries :p).
Its like the conversion step of PATH is missing in the second msys2.
However, I just did a few more tests and noticed the issue only occurs when I'm running msys2 from cmder. If I directly run a msys2.exe console, then vs code -> msys2, everything is fine with the path. But if I do the same from a msys2 terminal in cmder, the path is unconverted in the second msys2 instance.
I will investigate what is going on with cmder and close the issue if it's only related to it.
tanzislam
commented
4 years ago I had applied "delayed expansion" inside msys2_shell.cmd in #1836 to keep the Bash command line more intact. If Cmder was already working around the previous early-expansion behavior (by itself escaping the Bash command line) then it would break now.
MaximusSeniorem
commented
3 years ago Same issue for me. Here's what I found
Seems like the variable ORIGNAL_PATH is not 'cygpath-ed' when launching msys2 as a VSCode integrated terminal. I can't understand why though... (I litterally can't, since I couldn't find when this variable is supposed to be set)
extract of my vscode setting.json
"terminal.integrated.profiles.windows": {
"MSYS64" : {
"path" : "C:\\msys64\\msys2_shell.cmd",
"args" : ["-defterm","-mingw64","-no-start","-full-path"]
}
},
"terminal.integrated.defaultProfile.windows": "MSYS64"I got windows format
$ echo $ORIGINAL_PATH
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;...whereas launching msys2_shell.cmd with windows terminal with the exact same args outputs:
$ echo $ORIGINAL_PATH
/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:...
Konfekt
commented
1 year ago Hello, is it intended that echo $0 inside a shell script on C: shows a path starting with C:/ instead of /c/ ?
Hi, I'm using msys2 with MSYS2_PATH_TYPE=inherit, so my msys2 path contains my windows path. When I run msys2 normally everything is fine with $PATH and windows paths inside are converted to msys2 path, for example:
However, if a run a new msys2 instance from my current msys2 terminal, the path of the new instance is not correctly converted:
As a result, msys2 fails to find my binaries.
If you're wondering why I'm doing that, it's because I want to launch visual studio code directly from msys2, but then its integrated terminal that I configured to also run msys2 has the path issue I'm mentioning.
Do you have any idea where this come from ? Is it a known issue ? And do you have a workaround ?
Thanks for the answer and for your work on msys2 !