Description:
I recently upgraded vscode to the x64 build, and shortly afterward I noticed that the integrated terminal was no longer opening to the project root.
Steps to Reproduce:
PS:
Not sure if this is relevant or not, but the projects i'm opening are stored on a separate drive from the OS install drive. I mention this because any attempt to use terminal.integrated.cwd to remedy the situation seems to default the the C: drive.
I got terminal.integrated.cwd to work, but its my understanding that without this setting it should still default to the root directory that contains .vscode, which it is not doing.
If my understanding is incorrect, then my apologies and this issue can be closed.
@Zamerick can you elaborate on your settings? I'm switching to the Windows Store version of Ubuntu (the blog states that Bash on Ubuntu on Windows will be deprecated at some point). I figured out that
"terminal.integrated.shell.windows": "ubuntu.exe",
to get the terminal to launch at all since unlike before, using a path to sysnative (c:\windows\sysnativebash.exe) never actually launched the terminal.
Also, this #32188 seems related
Been working with Rust on my macOS laptop, and figured I'd continue on my Windows desktop tonight. So I setup the new WSL (much easier than it used to be) and set my integrated shell to the result of where ubuntu.
It works great, but it opens to home instead of the current workspace root. And not even my Windows home, it's showing my Ubuntu home instead.
I'm going to have to switch to Powershell for the time being, which is a shame. Powershell's a fine shell, I just prefer the bash ecosystem.
If you are getting an error when launching "bash.exe" but "ubuntu.exe" works, that means your default distro is not configured.
You can solve it by checking which distro's are installed with:
wslconfig.exe /l
and then setting default distro with:
wslconfig.exe /s Ubuntu
Enjoy fixed bash.exe !
Getting this issue as well. Mysteriously I was able to get it work once on another computer.
Invoking Ubuntu does not start in the project folder instead it goes to ~ for the following attempts:
ubuntu.exepowershell and use that to call ubuntuEdit: Using powershell in vscode you're able get to the project folder if you call wsl, or bash and the directory has no spaces. This is very unfortunate 😢
From OP:
Not sure if this is relevant or not, but the projects i'm opening are stored on a separate drive from the OS install drive.
This is not relevant since I only have one drive.
I had the same issue as above with my settings set to "ubuntu.exe", but when I switched back to "terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe" everything works fine. But I think this is an wsl issue. When opening from cmd and running ubuntu it starts at ~ and when running bash it starts at the cwd.
This appears to work now, I testing under 1.19.3/1.21.0-insiders and both launched in the workspace settings. I'm guessing Windows FCU fixed this.
I have the same problem with vscode 1.21.1 and "terminal.integrated.shell.windows": "ubuntu.exe". Opening a new terminal brings me to ~ instead of the cwd.
Can confirm that invoking a specific shell like ubuntu.exe or debian.exe will open the terminal and place you in ~. I tried using the terminal.integrated.cwd to take me to "${workspaceFolder}", but then my terminal would never open.
Changing my terminal.integrated.shell.windows to C:\Windows\sysnative\bash.exe was required for it to open the terminal in my actual workspace folder. Using the comments above to change your default shell to the one you would prefer in VS Code looks like the only workaround.
This seems like a WSL issue, as it used to work as expected when invoking a specific shell.
@bitcrazed any reason why the cwd will only be set correctly when using "bash.exe", not specific distros like "ubuntu.exe"?
@bitcrazed are you meant to use ubuntu.exe run bash to get the cwd to be set correctly when running distros? https://github.com/Microsoft/vscode/issues/50265 Seems messy if so? 😕
Add this to the catalog of things that appear like they should be simple, but end up being tricky.
When a distro's start-menu tile/pinned shortcut is clicked, the distro's launcher is executed (e.g. ubuntu.exe). To avoid starting the distro at c:\WindowsSystem32, we force distro launchers to start at home (~/).
When you run <distro>.exe from the command-line, you're launching the distro launcher, which starts session in home (~/).
However, if you execute <distro>[.exe] run, your distro starts-up in the cwd ... or at least it will when the distro vendors update their launcher to the latest code ;) @tara-raj is working with them on this!
Running wsl.exe, on the other hand, is able to start your distro in your cwd.
We are working on something to make this much more consistent - bear with us for now ;)
Also, this may be of interest: https://blogs.msdn.microsoft.com/commandline/2017/11/28/a-guide-to-invoking-wsl/
Could the cwd be used unless it was launched from System32? Alternatively the start menu shortcut could add an arg to start at ~?
Alas, adding tokens to start menu shortcuts isn't supported.
Also, what if the user IS at c:\WindowsSystem32 and WANTS to open their distro there?
We have a better solution that we're working on … bear with ;)
Thanks for the update, I'll close this off then as there's nothing to action on our side.
This was happening to me because my project folder had spaces in its path
Most helpful comment
If you are getting an error when launching "bash.exe" but "ubuntu.exe" works, that means your default distro is not configured.
You can solve it by checking which distro's are installed with:
wslconfig.exe /land then setting default distro with:
wslconfig.exe /s UbuntuEnjoy fixed
bash.exe!