My default profile does not have a "commandline" entry in the Ubuntu profile. It only has the “source” entry.

  {
    "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
    "hidden": false,
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl"
  },

If I add:

• "startingDirectory": null then bash opens in /mnt/c/WINDOWS/System32.
• "startingDirectory": "C:\\" then bash opens in /mnt/c.
• "startingDirectory": "~" then bash opens in /mnt/c/Users/jstor (windows home)
• "startingDirectory": "/home/jstorrs" then bash opens in /mnt/c/Users/jstor (windows home)

For comparison:

• wsl.exe will open in /mnt/c/Users/jstor (windows home)
• wsl.exe ~ will open in /home/jstorrs (ubuntu home)
• wsl.exe /home/jstorrs gives an error (it tries to execute /home/jstorrs)

So to me it looks like Windows.Terminal.Wsl is listening to “startingDirectory”, but I don’t know how to point it at a Ubuntu side path. So it mostly seems that the wsl.exe command has some extra logic to deal with ~ as a parameter.

When I googled this problem earlier the advice was to just put cd ~ to the end of .bashrc

I’m going to stick this on the 2.0 milestone to make sure we figure out a solution to this with the WSL team. I’m not sure why this is happening, but hopefully they’ll be able to give us some insight.

/fyi @benhillis @craigloewen-msft

Okay this is a spitball, but what happens if you add “startingDirectory”: null to those profiles?

I get the same result as @jstorrs, namely that it opens bash pointing at Windows/System32.

I am willing to concede that the default WSL Terminal profile behaves exactly the same way as just running wsl without any parameters but I would suggest that this is not the most desirable behaviour.

With WSL2, the strong recommendation is to stay within the Linux filing system because it is faster than the Windows filing system. The simplest way to achieve that is to specify “~” as the starting directory but using startingDirectory to do so doesn’t work, even in my second profile where I’ve commented out "source": "Windows.Terminal.Wsl".

There does need to be a cleaner way in Terminal of telling WSL where to start. While specifying a wsl$ path is a solution, it isn’t ideal - it isn’t very intuitive to novice users.

I was able to set the startingDirectory to my Ubuntu home following comments in the discussion here https://github.com/microsoft/terminal/issues/592

"startingDirectory": "//wsl$/Ubuntu/home/jstorrs"

I was able to set the startingDirectory to my Ubuntu home following comments in the discussion here #592

"startingDirectory": "//wsl$/Ubuntu/home/jstorrs"

That works!Thank u😉 But there maybe really needs a more human-friendly way to set the default wsl dir.

I’ve been using the app execution aliases for my WSL distros in my WSL configs, and it works great.

For anyone wanting to reference numbered Ubuntu builds, the names are like ubuntu2004.exe and ubuntu1804.exe.

This is a great tip, @ocitrev - thanks.

I’ve been using the app execution aliases for my WSL distros in my WSL configs, and it works great. When run without arguments, they launch the user’s default shell in the user’s home. No need to set the startDirectory.

{
    "guid": "{31b0ca0b-67d0-479d-901d-31b29cf05a42}",
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl",
    "commandline": "Ubuntu.exe"
},
{
    "guid": "{f752f8d9-f2aa-4761-9eff-bc857a48e281}",
    "name": "kali-linux",
    "source": "Windows.Terminal.Wsl",
    "commandline": "Kali.exe"
}

This just reoccurred for me.

I was using "commandline": "wsl.exe -d Ubuntu-20.04" "startingDirectory": "//wsl$/Ubuntu-20.04/home/craig"

I had to change the command line to "commandline": "wsl.exe ~ -d Ubuntu-20.04"

Thanks to jstorrs for the hint.

This might be fixed, or at least mitigated by #9223