WSL home directory behaviour unexpected

[pcolmer]

Environment

Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 1.1.2021.0
Ubuntu 20.04.1 LTS

Steps to reproduce

1. Install Ubuntu 20.04 as WSL.
2. Start the default Ubuntu terminal.

Expected behavior

I would expect the terminal to start in the home directory of the user.

Actual behavior

The terminal starts at "/mnt/c/Users/phili", which is the Windows home directory.

Other notes

If you add a duplicate terminal profile, change the guid and comment out the source, it works as expected.

            {
                "guid": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "commandline": "wsl.exe ~"
            },
            {
                "guid": "{daaee0d5-f525-4b10-98d1-d0ed1ede9f72}",
                "hidden": false,
                "name": "Ubuntu-no-source",
                // "source": "Windows.Terminal.Wsl",
                "commandline": "wsl.exe ~"
            },

In other words, the first profile above is the default one provided by Terminal. The second profile is my "hacked" one. The first one dumps me in my Windows home directory. The second one puts me in my Linux home directory.

In #6022, it was suggested that the behaviour changed depending on what had already happened, e.g. opening order or if WSL was already running. I took a video to show that this didn't seem to be the case for me.

[zadjii-msft]

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

[jstorrs]

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

[jstorrs]

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

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

[pcolmer]

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.

[Chris-Teng]

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.

[zadjii-msft]

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

[benhillis]

Seems like Windows.Terminal.Wsl is overwriting something?

[ocitrev]

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"
}

[pcolmer]

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.

[zadjii-msft]

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

[plastikfan]

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

Using that 'cd ~' in your shell's initialisation script is a bad idea. If you do so then if you open up vscode, then open an integrated terminal, it will also open in the home directory instead of the desired default behaviour of opening the workspace root directory. I tried to change this by configuring vscode (setting (for WSL remote): terminal.integrated.cwd to ${workspaceFolder}) but this does not work.

At last, I found something that works, in the windows terminals settings, set the starting directory to:

• \wsl$<distro-name>\home<username>

eg:

\\wsl$\Ubuntu-20.04\home\username

As directory names in linux are case sensitive, make sure the username is cased properly, or else it won't work.

[swahilli]

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.

[emrszon]

"startingDirectory": "/home/jstorrs"

This work for me.

Thanks to @jstorrs for the hint.

[DHowett]

The coming 1.12 release (and 1.13, if you are using Preview) is going to make this much more ergonomic. For profiles that launch wsl.exe, you will be able to use Linux paths in startingDirectory, and the default is ~ for all automatically generated WSL profiles. The fix was made in part in #9223 and in part in #12315 (fix in #12437; don't let the name mislead you :P)