Terminal: WSL home directory behaviour unexpected

Created on 6 Aug 2020  路  9Comments  路  Source: microsoft/terminal

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.

Area-Settings Issue-Bug Priority-1 Product-Terminal Product-WSL

Most helpful comment

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

All 9 comments

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

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

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 #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 get the same problem.

Environment
winver: OS Build 19041.388
windows terminal version: 1.1.2233.0
wsl distro: Ubuntu(20.04) from Microsoft Store.
wsl version: 2

Expected

open wsl tab with user home directory that in wsl, specifically is /home/brs.

Reproduce

"source": "Windows.Terminal.Wsl",
"startingDirectory": "//wsl$/Ubuntu/home/brs",

will open with /mnt/c/Users/brs.

"source": "Windows.Terminal.Wsl",
"commandline": "wsl.exe ~ -d Ubuntu",
"startingDirectory": "//wsl$/Ubuntu/home/brs",

will open with /mnt/c/Users/brs.

"commandline": "wsl.exe ~ -d Ubuntu",
"startingDirectory": "//wsl$/Ubuntu/home/brs",

will open with /mnt/c/Users/brs.

"commandline": "wsl.exe ~ -d Ubuntu",

will open with /mnt/c/Users/brs.

"source": "Windows.Terminal.Wsl",
"commandline": "wsl.exe ~ -d Ubuntu",

will open with /mnt/c/Users/brs.

Additional info

Run wsl.exe ~ -d Ubuntu in powershell is works fine.

hmmm... It seems like I have declared two wsl profiles in my settings.json.

like this:

{
    "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
    "hidden": false,
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl",
},
{
    "guid": "{1cd32e5c-c707-4699-b105-f99539dc0776}",
    "hidden": false,
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl",
     "startingDirectory": "//wsl$/Ubuntu/home/brs",
}

I commented out one of them, and it worked.

Plz ignore my previous comment.

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

Seems like Windows.Terminal.Wsl is overwriting something?

Was this page helpful?
0 / 5 - 0 ratings