"Open Windows Terminal here" does not continue to work for subsequent tabs, panes

[TigerBeanst]

Environment

Windows build number: 10.0.19042.0
Windows Terminal version (if applicable): 1.5.10271.0

Any other software?

Steps to reproduce

1. Click "Open Windows Terminal here" in directory
2. Click WSL or CMD (anything that different than the default tab)
   

Else, I have been add startingDirectory in setting:

"profiles":
    {
        "defaults":
        {
            "startingDirectory" : "."
            // Put settings here that you want to apply to all profiles.
        },

Expected behavior

For example, I click "Open Windows Terminal here" in D:\Games.
What I think it should be:

Actual behavior

My default tab is Powershell7, it works well:

But if I switch to WSL or CMD:

the path goes to C:\Windows\system32.

Other

I now use this for me:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt]
@="Open in Windows Terminal here"
"Icon"="%USERPROFILE%\\AppData\\Local\\terminal\\wt_32.ico"

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command]
@="C:\\Users\\hjthjthjt\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe"

It works as my expect. But the new feature "Open Windows Terminal here" does not.

[zadjii-msft]

Hmm. Looks like we're only applying the "open in Windows Terminal" to the first tab that's created. So wt.exe's CWD is still c:\windows\system32, meaning subsequent tabs opened with . as a startingDirectory would use c:\windows\system32.

I think there's another issue floating around here tracking something similar, but I for the life of me can't find it.

For this one, maybe we shouldn't ONLY be doing wt -d <the path from explorer> - maybe there's some way to set the CWD for the child process itself? I'd assume that wt would inherit it from it's parent explorer.exe, but maybe we're doing something wrong here.

[KalleOlaviNiemitalo]

What is the expected behaviour if "Open Windows Terminal here" in some future version opens a new tab in an existing Windows Terminal window (related to #4472 but not necessarily using wt.exe), and the user then uses the profile menu to start another session with "startingDirectory": "." in that window?

I think Windows Terminal should resolve "startingDirectory": "." from the current directory of the active session of the window whose profile menu the user used. The current directory of each session could be changed with OSC 7 (#3158) and would default to the starting directory of the session, such as the directory received from "Open Windows Terminal here".

[patricknelson]

My workaround to address this (to ensure that new panes/tabs open with the same starting directory) is to do the following:

1. Use BroJenuel/Explorer-Context-Menu-Integration-for-windows-terminal for right-click integration instead.
2. Remove the duplicate entry using the registry fix documented here: How to remove "Open in Windows Terminal" from context menu? #7008 (comment)

Demo:

[Dominiquini]

The last version of Windows Terminal (1.7.1033.0) have the option "Use parent process directory", that I should do what I wanted, but it is not working! Only the first profile open in the directory I choose. But when I create a new profile in a new tab, it opens in the "C:\Windows\system32" directory.

[rafrafek]

For me it is not only not working, but also breaks Git Bash:

• history of commands is not saved,
• settings like .inputrc are not loaded,
• some programs like ssh are totally broken.

This is my output from Windows Terminal, from Git Bash, when opened via "Open in Windows Terminal" context menu, then new tab:

$ ssh foo
vdollar_percent_expand: unknown key %H
percent_dollar_expand: failed

When Windows Terminal is opened via Menu Start everything works perfectly.

[zadjii-msft]

@rafrafek That's certainly unexpected, but very weird that your git bash profile would behave so differently if the starting directory was C:\windows\system32 instead of whatever directory you clicked on. Could you share the contents of your git bash profile in settings.json?

[rafrafek]

@zadjii-msft Yes, sure. It looks like this:

...
"defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "profiles": 
    {
        "defaults": 
        {
            "useAcrylic": false
        },
        "list": 
        [
            {
                "commandline": "%PROGRAMFILES%/Git/usr/bin/bash.exe -i -l",
                "guid": "{00000000-0000-0000-ba54-000000000002}",
                "icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico",
                "name": "Bash",
                "startingDirectory": "%USERPROFILE%"
            },
            {
                "commandline": "powershell.exe",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
...

[KalleOlaviNiemitalo]

vdollar_percent_expand: unknown key %H is a message from OpenSSH.

I wonder if the %H is part of something like %HOMEDRIVE% in the value of an environment variable. @rafrafek, which version of Windows Terminal are you using? Windows Terminal Preview suffers from #9741, which is known to leave % signs in the value of the PSModulePath environment variable and might possibly also affect some environment variable that ssh examines.

[rafrafek]

@KalleOlaviNiemitalo It is 1.7.1033.0 installed from GitHub releases.

[KalleOlaviNiemitalo]

@rafrafek, in the Git Bash session in which ssh does not work, does the value of the HOME environment variable contain any percent signs? If it does, that would explain why Bash does not find .inputrc.

[rafrafek]

@KalleOlaviNiemitalo Yes!
Bad session opened via "Open in Windows Terminal":

$ echo $HOME
/c/Users/xxx/%HOMEDRIVE%%HOMEPATH%

Good session opened via Menu Start:

$ echo $HOME
/c/Users/xxx

Where xxx is my login.

[KalleOlaviNiemitalo]

OK, I can reproduce on Windows 10 build 19042.928 if I define "HOME" = REG_EXPAND_SZ "%HOMEDRIVE%%HOMEPATH%" as a user environment variable like so:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Environment]
"HOME"=hex(2):25,00,48,00,4f,00,4d,00,45,00,44,00,52,00,49,00,56,00,45,00,25,\
  00,25,00,48,00,4f,00,4d,00,45,00,50,00,41,00,54,00,48,00,25,00,00,00

• Start Windows Terminal 1.7.1033.0 from the Start menu. It opens a PowerShell session. $env:HOME has the expanded value. Open a Command Prompt session in another tab. set HOME displays the expanded value.
• Start Windows Terminal 1.7.1033.0 from the shell extension (window background). It opens a PowerShell session. $env:HOME is literally %HOMEDRIVE%%HOMEPATH% unexpanded. Open a Command Prompt session in another tab. set HOME displays HOME=%HOMEDRIVE%%HOMEPATH%.

The incorrect value of the environment variable thus shows up both in the original tab and the subsequently opened tab. Also, this happens even if settings.json does not specify "startingDirectory" at all. Therefore, I think the problem with ssh is distinct from this #8933.

Process Monitor shows that the wt.exe process gets the unexpanded HOME=%HOMEDRIVE%%HOMEPATH% in its environment block when the shell extension starts it. The shell extension is loaded to a DllHost.exe process, which likewise gets the unexpanded HOME=%HOMEDRIVE%%HOMEPATH% when svchost.exe starts it.

According to #9741 (comment), Windows loads HOMEDRIVE and HOMEPATH only after it has already loaded REG_EXPAND_SZ values from "HKU\<SID string>\Environment". However, the "Environment Variables" dialog box of Windows displays the expanded value if I configure HOME as %HOMEDRIVE%%HOMEPATH%. Because of that, I think this is a bug in Windows, although Windows Terminal could be changed to work around it.

[ghost]

🎉This issue was addressed in #10546, which has now been successfully released as Windows Terminal v1.9.1942.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #10546, which has now been successfully released as Windows Terminal Preview v1.10.1933.0.:tada:

Handy links:

• Release Notes
• Store Download