Vscode: Integrated terminal does not open to project root using WSL

Created on 17 Aug 2017  Â·  16Comments  Â·  Source: microsoft/vscode

  • VSCode Version: 1.15.1 x64
  • OS Version: Windows 10, WLS: Ubuntu 16.04.3 LTS
  • Terminal Used: zsh/oh-my-zsh
  • Reproduces without extensions: Yes

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:

  1. Open Folder/Project with or without .vscode workspace settings.
  2. Open Integrated terminal
  3. Terminal opens to '~' instead of project root.

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.

WSL help wanted integrated-terminal needs more info windows

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 /l

and then setting default distro with:

wslconfig.exe /s Ubuntu

Enjoy fixed bash.exe !

All 16 comments

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:

  • Default terminal is directory to ubuntu.exe
  • Default terminal is powershell and use that to call ubuntu

Edit: 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? 😕

  • @tara-raj

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

Was this page helpful?
0 / 5 - 0 ratings