Opening Windows Terminal in current directory from right-click folder context menu (the ubuntu.exe bug)

[marcodiiga]

Description of the new feature/enhancement

I couldn't find a way to open up wt.exe in a linux profile (e.g. Ubuntu) via right-click in the context menu that pops up in explorer by setting the current working directory to whatever I was browsing before.

To rephrase: I added some HKCR\Directory\Background\shell\wt\command key with wt.exe -d "%V" so that I can Shift+RightClick in a folder in explorer.exe and have a Open in Windows Terminal with Linux item in the context menu. Windows Terminal opens but the starting directory, no matter what I set the profile startingDirectory field in the JSON to, is always set to my home directory. It would be nice if wt.exe -d "C:\\" or whatever actually opened, for the linux profile, in /mnt/c as starting directory.

[zadjii-msft]

What version are you on? Could you share your settings.json file?

I'm mildly worried that our ~ auto promotion may have accidentally interfered with the ability to use the explorer context menu entry with a WSL profile 😬

aside: Is there a reason you're not just using the explorer context menu entry that the Terminal creates itself when you install it/?

[marcodiiga]

Sure, here's my settings.json:

{
    "$help": "https://aka.ms/terminal-documentation",
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "actions":
    [
        {
            "command":
            {
                "action": "copy",
                "singleLine": false
            },
            "keys": "ctrl+c"
        },
        {
            "command": "paste",
            "keys": "ctrl+v"
        },
        {
            "command": "find",
            "keys": "ctrl+shift+f"
        },
        {
            "command":
            {
                "action": "splitPane",
                "split": "auto",
                "splitMode": "duplicate"
            },
            "keys": "alt+shift+d"
        }
    ],
    "copyFormatting": "none",
    "copyOnSelect": false,
    "defaultProfile": "{51855cb2-8cce-5362-8f54-464b92b32386}",
    "language": "en-US",
    "profiles":
    {
        "defaults": {},
        "list":
        [
            {
                "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
                "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
                "hidden": false,
                "name": "Windows PowerShell"
            },
            {
                "commandline": "%SystemRoot%\\System32\\cmd.exe",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
                "hidden": false,
                "name": "Prompt dei comandi"
            },
            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "%USERPROFILE%"
            },
            {
                "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
                "hidden": false,
                "name": "Azure Cloud Shell",
                "source": "Windows.Terminal.Azure"
            },
            {
                "guid": "{5b849eef-e172-55b9-8019-ef031bec368c}",
                "hidden": false,
                "name": "Developer Command Prompt for VS 2022",
                "source": "Windows.Terminal.VisualStudio"
            },
            {
                "guid": "{8c6e956b-317a-5194-b80e-c5281032870f}",
                "hidden": false,
                "name": "Developer PowerShell for VS 2022",
                "source": "Windows.Terminal.VisualStudio"
            },
            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
                "startingDirectory": "%USERPROFILE%"
            }
        ]
    },
    "schemes":
    [
       ... unimportant I guess...
    ]
}

For the second question: the context menu entry created at install time doesn't set the starting directory to the current one I was browsing while I clicked with Shift+RightClick either, seems to work with the WSL profile, not with the other Ubuntu profile.

[zadjii-msft]

            {
                "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
                "hidden": true,
                "name": "Ubuntu",
                "source": "Windows.Terminal.Wsl",
                "startingDirectory": "%USERPROFILE%"
            },
			// ...
            {
                "guid": "{51855cb2-8cce-5362-8f54-464b92b32386}",
                "hidden": false,
                "name": "Ubuntu",
                "source": "CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc",
                "startingDirectory": "%USERPROFILE%"
            }

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

[zadjii-msft]

Interesting. I really can't get this to repro... Is this always affecting a specific path? I know there have been troubles with doing this in the root of a drive before (e.g. c:\, or D:\), but child directories seem to work fine.

Which OS version and Terminal version are you on/? IIRC there were some os-side issues with Directory/Background entries in the past

[marcodiiga]

Windows 10 (10.0.19044 Build 19044), wt 1.12.10982.0. It is affecting any path that I could try, not only root drives but also child dirs.

[marcodiiga]

I found a workaround to make this work: this opens up the shit+right-click context menu directory in Windows Terminal in the default profile (which I have set to Canonical's own profile).

[zadjii-msft]

Oh heck that's probably it! I bet they've got the commandline of their profile set up so that it doesn't actually obey the startingDirectory!

[jacob-pro]

Is your profile using wsl.exe -d Ubuntu or Ubuntu.exe?

The latter will not respect the starting directory, and always opens in $HOME

[zadjii-msft]

The latter will not respect the starting directory, and always opens in $HOME

That's exactly it. There's definitely and issue with the Ubuntu profiles that Canonical is shipping. Sorry about that! I'm reaching out to them to see what we can do here.

[trizotti]

Same problem here after removing one of the distros I had installed; Windows Terminal settings also still recognizing two distros at the selection for the default one.

[mrtumnus]

Workaround - add the following in .bashrc inside WSL:

# Change starting directory for the default system directory
if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then
  cd ~
fi

[mrtumnus]

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

Did you ever figure out why we have two? Which one should we use?

[nrobinson12]

Workaround - add the following in .bashrc inside WSL:

# Change starting directory for the default system directory
if [ "$PWD" = "/mnt/c/WINDOWS/system32" ]; then
  cd ~
fi

Thank you! Why didn't I think of this?

[mrtumnus]

Thank you! Why didn't I think of this?

Can't really think of a downside, unless you explicitly want to open terminal in the system directory.

The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in $HOME in this case. Still have to look around issues here to see if it's reported already.

[DHowett]

The only thing that still doesn't work with this setup is opening terminal within a network share. It ends up landing in $HOME in this case. Still have to look around issues here to see if it's reported already.

WSL does not automatically map network shares. It cannot be launched in any directory that is not represented or representable in the Linux filesystem. You would need to mount them explicitly in /etc/fstab, and even then it may not be able to figure it out.

This would make an excellent feature request for the WSL repo 😄

[mrtumnus]

WSL does not automatically map network shares.

I could have sworn I had this working in WSL2. But I could be getting confused with my previous cygwin setup.

[DHowett]

Ah, even WSL 1 doesn't automatically map network shares.

[pbodnar]

Interesting - canonical is shipping their own profile, but not one layered with the existing profile. Curious....

Did you ever figure out why we have two? Which one should we use?

Exactly my question. Why are 2 profiles generated and the bad one is enabled and not vice versa?

From all the related bugs, the profile generated by ? (with the Tux icon) is the correct one and the one generated by Canonical (with the Ubuntu icon, ubuntu.exe) is wrong. So why is it so that both profiles are generated and moreover that the correct one is disabled by default? Basically, it comes to the question, why the WSL / Terminal team cannot do anything about this (yet)?

IMO, from user's perspective, this seems absurd, so it would deserve at least a short explanation. And also a dedicated issue like #15560 - @zadjii-msft, are you really sure you want to continue the discussion here, where logically stuff quite unrelated to this profiles bug (like "mapping network shares" just above) were and will be discussed?

Anyway, thank you guys for pushing this further, I believe this confuses tons of people and is a huge waste of time in the sum.

[TBBle]

From all the related bugs, the profile generated by ? (with the Tux icon) is the correct one and the one generated by Canonical (with the Ubuntu icon, ubuntu.exe) is wrong. So why is it so that both profiles are generated and moreover that the correct one is disabled by default? Basically, it comes to the question, why the WSL / Terminal team cannot do anything about this (yet)?

This is a choice in the Canonical code snippet, it creates a new profile and (attempts to) disable the built-in generator's profile. Nothing we can do about it in the WT code except break that feature, which seems unlikely to be an acceptable choice.

---

Having just help a user hitting this issue starting from #3158 (comment), here's what appears to be the current state of making the Ubuntu-provided profile (or any other WSL distribution's custom profile) work, thanks to comments earlier in this ticket, and some testing by the user having the issue.

If you want to use the Ubuntu generated profile, you need to do one of two things:

1. Add a snippet like this to the generated profile, mirroring the built-in settings from the WSL-provided profile and hence activating a wsl.exe-specific codepath.

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

Note that this approach loses anything the Ubuntu launcher does before it chains out into wsl.exe. I think that is only first-run stuff, but I expect it does make this approach a non-starter for the Ubuntu-provided snippet.

2. Add a snippet like this to the generated profile, getting the desired "don't override CWD" behaviour from the Ubuntu-provided launcher with the run argument plus an explicit default startingDirectory to not start in C:\Windows\System32:

    "commandline": "ubuntu2204.exe run",
    "startingDirectory": "\\\\wsl$\\Ubuntu-2404\\home\\<yourWSLAccountName>",

You can get the startingDirectory value for option 2 from inside Ubuntu by going to the desired directory and running wslpath -w "$PWD", or browsing from \\wsl$ or \\wsl.localhost in Windows Explorer.

In both cases the commandline value will depend on the existing command-line: If you do it in the GUI editor, you should see the existing command line.

Both approaches should make both "open-in-current-directory folder context menu" and "OSC9;9 duplicate current session" work, as AFAIK they rely on being able to override the profile's defined startingDirectory, as does wt newtab -d. However, neither approach will make drag-and-drop path mangling work.

Note that if you're adding cd calls to your bash startup scripts, they should not be necessary with the above two approaches. You can still use #12961 (comment) to avoid setting the startingDirectory with only the minor cost of not being able to start in C:\Windows\System32... And it not working if you aren't actually running bash. So I personally disprefer this approach.

---

There's two current code-paths in WT that are issues for this ticket AFAIK:

• Code that handles "startingDirectory": "~", depends on the commandline starting with wsl.exe or C:\Windows\System32\wsl.exe.. Without it, you have to provide the full path to your WSL user's home directory. (This code could be improved to only pass --cd on the command-line when the startingDirectory is ~ or starts with ~, as those are the only times it actually matters. Edit: See following comment for correction)
• Code that handles drag-and-drop path mangling depends on the profileSource being literally Windows.Terminal.Wsl.

So there's probably some low-hanging fruit for someone to unify those two hacks to both work the same way. (Of the two hacks, I think matching wsl.exe is better than checking the profileSource, since approach 1 above has fewer side-effects that changing the profileSource value would have)

And some higher-branch fruit to then expose them as not-hacks by perhaps either detecting WSL or exposing an isWSL flag in the profile that activates both hacks and probably also provides a default "startingDirectory": "~" value.

Other solutions are possible, of course, and I make no suggestion on the acceptability of my suggestions to the WT maintainers.

[DHowett]

This code could be improved to only pass --cd on the command-line when the startingDirectory is ~ or starts with ~, as those are the only times it actually matters.

Thanks for the investigation! One note about this: we use --cd to support startingDirectory set to things like /root or perhaps more saliently /tank/projects/foo. It does not only apply to homedir based paths.

[TBBle]

Ah, yes. I misparsed the code: the ~ check I skimmed over is an exclusion check for the provided command-line.

So it does make sense to use --cd in the case where we know it exists (I'm not sure if the template WSL Distribution Launcher handles it, on consideration, as I don't know if that's handled by wsl.exe directly, or by the underlying API shared by the template WSL Distribution Launcher), even though it's not needed for Windows-filesystem paths, rather than trying to distinguish them here.

[reardonia]

Is there any way to extract the value set via OSC9;9 and use within "commandline" ? How do we generalize the dup functionality to work for ssh sessions (and other arbitrary commands)? It seems like it can only be used for WSL/cmd/PS sessions.

something like :
{ "commandline": "ssh.exe -t myname@myserver \" cd %PWD% ; bash --login \" ", }

[TBBle]

I think that this is the wrong ticket for this question...?

But no, I don't think that data is currently exposed in env-vars or otherwise, it's only used to set the starting directory for the new process as far as I can see. (But I only quickly checked the code for launching processes on GitHub, so it's possible it's exposed somehow elsewhere and I overlooked it.)

That should already work for arbitrary commands, as long as they also output OSC9;9 escapes to set the value, e.g., vim.exe could be used with the current system with a vim plugin that outputs OSC9;9 when you change CWD inside vim use :cd or autochdir by hooking the DirChanged autocmd. It's only specific things like ssh or plink where the process's starting directory is not where we actually need this information.

So you would need to open a feature request ticket if you want that available.

Note that OSC9;9 paths are Windows paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158.

But maybe the resolution to the long standing "OSC7 semantics are challenging and ill-defined" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\" or wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH% on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT should care about: setting the starting directory for the new process.

Okay maybe it is relevant to this ticket; if WT_OSC7_PATH defaulted to startingDirectory when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal --cd %WT_OSC7_PATH% before env-var handling.

But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...)

[reardonia]

Note that OSC9;9 paths are Windows paths, so unless you're SSHing to a Windows server, it won't be the right value for you anyway. For that, you'll need OSC7 support, and we don't have that in Windows Terminal yet, it's being "tracked" in #3158.

Hmm, I don't think that's right? For instance, from a WSL session I can emit OSC9;9 with a linux path, using "\w" escape that bash understands with PS1 environment variable. I don't have to "window-ize" the path using wslpath. Focus-panes duplicate properly and inherent the PWD.

It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly)

[reardonia]

But maybe the resolution to the long standing "OSC7 semantics are challenging and ill-defined" issue for us could be as simple as "Capture OSC7, and expose it as an env-var in duplicate tabs so people can use a commandline like ssh.exe -t myname@myserver \"cd %WT_OSC7_PATH% ; exec ${SHELL}\" or wsl.exe -d Ubuntu-22.04 --cd %WT_OSC7_PATH% on their own recognisance", and not try and actually implement any specific behaviour for OSC7, since OSC9;9 fills its use-case in all situations that WT should care about: setting the starting directory for the new process.

Okay maybe it is relevant to this ticket; if WT_OSC7_PATH defaulted to startingDirectory when that is a POSIX-style path, then this pattern might let us remove one of the WSL-specific hacks (at the cost of putting it explicitly in the WSL profile commandline), or at least simplify it to implicitly adding literal --cd %WT_OSC7_PATH% before env-var handling.

But I still think the general idea of "Capture OSC7 and expose it as an env-var for commandlines/processes to use as they see fit" might be worth a feature request. (That would also let us close #3158 as "We're not using OSC7 for automatic CWD setting, we only support OSC9;9 for that"...)

I'd happy with either OSC7 or OSC9;9 turning into an env var, and dropping WSL-specific hack. I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder.

EDIT: I just found MangleStartingDirectoryForWSL() ... YUCK!

[TBBle]

It's not at all clear in the code that OSC9;9 can only refer to a Windows path? (though I am new to this codebase, I just scanned quickly)

It's actually per the spec of OSC9;9 as far as I recall. Edit: I dreamed this, apparently. The spec is literally "Inform ConEmu about shell current working directory". I have no idea if or how ConEmu deals with non-Windows paths here. Edit: It fails. ConEmu's msys/cygwin connector appears to convert paths in OSC9;9 before passing them up to ConEmu, so ConEmu users aren't habitually using cygpath/wslpath, but it works fine if they do.

The only reason it works with WSL profiles without wslpath is because WT doesn't validate the path at all, and then the existing hack to make in-WSL paths work kicks in.

If we ever implement a feature to open other profiles with the current directory then you'll need to be using wslpath if you want to open, e.g., pwsh in the same directory as your current WSL session.

Even right now, if you open a pwsh session, and run WSL inside it, without wslpath'ing your OSC9;9 path, duplicating the tab will open pwsh in your profile directory, not your last pwsh path, nor your current WSL path. fail to start pwsh. MangleStartingDirectoryForWSL will only catch the case of a ~, which PWD should never be, and otherwise lets the POSIX path through which then fails because (unless you're very lucky) there's no such directory on Windows.

So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises.

[TBBle]

I don't totally follow the argument for why OSC9;9 was introduced vs reusing OSC7 but I'll leave that to others who've thought about it longer/harder.

Basically, everytime someone from the Windows world tried to implement OSC7, a bunch of corner cases showed up for POSIX paths, and we also re-learned that Windows defines the file: url differently in different places.

OSC9;9 is specific to Windows-based terminal emulators so it was easier to implement first.

[reardonia]

So I'd strongly suggest using wslpath now to avoid future "Why doesn't it work now?" surprises.

I don't follow. This is exactly what breaks in the 'ssh' scenario, where wslpath is not available.

In any case, should I attempt to file a a feature request (to make either OSC9;9 or OSC7 info available via env var) or presume that it will implicitly follow from this discussion?

[TBBle]

I was referring to the comment about WSL sessions apparently not needing wslpath in the OSC 9;9 script. I would strongly not recommend sending OSC9;9 back from remote SSH hosts, as that is out-of-spec; even OSC7 was intended for local-only use, but as I mentioned when someone tried to standardise it, a bunch of questions like "What do we do about SSH" appeared and the whole thing was stalled.

Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var".

[reardonia]

Anyway... yes, I'd recommend filing a feature request; that way it'll be more clearly in front of the project developers, and if nothing else, should receive feedback on better ways to achieve what you need, and/or better implementations that "Expose as env-var".

#17980