Feature Request: Path translation in WSL and Git Bash

[Forinil]

Summary of the new feature/enhancement

It would be useful if the path pasted from clipboard to a shell was translated to a format that said shell understands if it differs form native windows format.

For example, if user pastes C:\Windows\System\ to PowerShell or cmd it remains unchanged, but in WSL it changes to /mnt/c/Windows/System and in Git Bash to /c/Windows/System.

[eberkund]

I wonder if this would be implementable in a generic way such as by having two settings like this for Git bash:

"pathConversionForwardSlashes": true,
"pathConversionRemovePrefix": "C:\",
"pathConversionReplacePrefix": "/mnt/c/"

[Forinil]

The prefixes would have to be regular expressions to acount for the fact that C is not the only possible drive letter.

Maybe something like:

"pathConversionExpression": "|([A-Za-z])\(.*)|/mnt/\L$1/$2|"

where $1, $2, ... are capture groups and \L is a lowercase operator (like in Notepad++).

[eberkund]

Yeah you're right, I guess full blown regex would be a better solution at that point.

[ToadKing]

A better solution IMO would be to use the path conversion commands command built into WSL and Cygwin/MSYS2/Git Bash/etc. to convert it for us. So for WSL you would have:

"pathConversionCmd": "wsl wslpath -a $1"

And for Git Bash you could have :

"pathConversionCmd": "\"C:\\Program Files\\Git\\usr\\bin\\cygpath.exe\" -a $1"

[eleniums]

Any traction on this issue? It seems small, but this is actually a major roadblock to me switching from cmder to Windows Terminal.

[Daniel599]

A better solution IMO would be to use the path conversion commands command built into WSL and Cygwin/MSYS2/Git Bash/etc. to convert it for us. So for WSL you would have:

"pathConversionCmd": "wsl wslpath -a $1"

And for Git Bash you could have :

"pathConversionCmd": "\"C:\\Program Files\\Git\\usr\\bin\\cygpath.exe\" -a $1"

I was looking into implementing this, I really like the idea but also I started thinking;
what about security issues? that config field will allow anyone to run any executable by hijacking the settings file (even with admin permissions if the terminal was opened that way).
Should I do the regex instead? or detect it's wsl and support only that?
another idea (which I don't like, but still throwing it out there): ability to add a wrapper: path --> wslpath "*path*" (note the addition of ` character)
@zadjii-msft @DHowett-MSFT what do you guys think?

[zadjii-msft]

You know what, we've got a team sync later today, I'll bring this up. We had a plan for WSL distros that would just work like magic, but that would not work at all for mingw profiles. Let's see if we can come up with something.

I don't love the idea of putting an arbitrary exe into the settings file itself. It's definitely a possible security hole. We might be able to hack around this temporarily with

• A. making this an experimental. setting, in case we come up with a better plan
• B. letting this only work in unelevated windows. I know that's annoying, but prevents an escalation-of-privilege whereby an unelevated malicious.exe from changing your settings.json so that pathConversionCmd is set to malicious.exe instead

[Daniel599]

@zadjii-msft any update in that matter?
In the meanwhile I think I`ll try to implement #10073, as it seems to use working-dir to convert path so maybe those two issues are ortogonale

[zadjii-msft]

My apologies. A bunch of the team was out sick last week, so we ended up just not having the meeting 😬 Hopefully everyone's feeling better this week (and we're not to preoccupied with last-minute //Build fires)

[zadjii-msft]

notes from team sync: someone recalled vaguely that ConEmu has a solution for this that doesn't involve launching another exe to resolve that path. Maybe we should take a look at what they do, and see if that makes sense to emulate.

[skyline75489]

Here's the documentation of Shell working dir in ConEmu for reference: https://conemu.github.io/en/ShellWorkDir.html

I see ConEmuC.exe which is a native win32 application that seems to handle path resolution.

Also tips for @Daniel599: Dustin no longer uses the account DHowett-MSFT for this project. He's now @DHowett .

[lingyanmeng]

This is the only issue that blocks me to switch to Windows Terminal. Solution wise, I would suggest adding an option in the profile -> Advanced, the option can be called: "Convert Windows path to Linux path during paste"

[zadjii-msft]

@lingyanmeng I would love to do that. How would we know to translate the path depending on WSL vs Cygwin vs msys?

I was under the impression that windows-side paths were in different places for those various different linux-like installs.

[shinayser]

Any update on that issue?

[zadjii-msft]

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

• Automatically convert paths dropped on WSL instances #11625 added support for translating drag/dropped WSL paths.
• We'd still need to do something similar if the clipboard contained a path (this issue)
• Open new terminal tab in same directory as existing tab (OSC 7?) #3158 is for tracking "the shell told us it was in {WSL path}, which we can actually reverse engineer to {Windows path}"
• There's still no good solution for cygwin/msys paths. That's not something we control, so we're not really planning on adding tighter integration with that. Throwing arbitrary exe's in the settings to have the Terminal execute seems generally like a bad idea.

[MattBussing]

Do you guys mind increasing the priority of this issue? It would be nice to be able to smoothly paste a file path. 😄

[zadjii-msft]

We certainly don't have the capacity to get to this ourselves any time soon, sorry 😕. If someone wants to help sort out the bits of this to enable this for WSL distros, I'd be more than capable to give pointers of where I'd start. The "use an exe to translate the path" seems a bit more... risqué, but the "I know the thing running in this terminal is this WSL so we can translate the path {like so}" seems pretty doable.

[MattBussing]

Thank for for the quick reply! I don't plan on working on it at the moment.

[voltuer]

i'm pretty sure to have seen this at some point some time ago, i dragged a folder to terminal with ubuntu open on it, and it replaced the path to the corresponding /mnt/c path, but i can't see it working now 🤔

[zadjii-msft]

@sebolio This only works for panes created for profiles with a Microsoft.Terminal.WSL source set. There's a set of "source": "CanonicalGroupLimited.Ubuntu* profiles floating around, where that won't work. That's vaguely tracked in #14233, #14003 and #12961

[ParadoxV5]

#11625 detects whether the profile is WSL buy checking for "source": "Windows.Terminal.Wsl" in the configs (which isn’t exposed to the Settings UI because why should we?). This means manually-created WSL profiles, such as my Interactive Ruby (wsl irb), don’t get the same VIP treatment.

Please, either

• Detect WSL from the start-up command (/\Awsl(.exe)?/) rather than that arcane setting
• Make path translations manually customizable – users get to decide whether to translate or not.
  • The automatic profile from WSL installation will instead be created with this config set to translating Windows paths to Linux.

[DHowett]

which isn’t exposed to the Settings UI because why should we?

Because that setting literally tracks where the profile came from. There is no meaningful change you can make to it (and if you do, the profile will get deleted. Because the thing you said it "came from" can't attest that it came from there. That's actually how we automatically hide profiles for WSL distributions that you uninstall!)

In general, detecting what a profile is running versus where a profile came from is difficult and annoying.

Even these proposed solutions don't work for the case where you run wsl from within PowerShell, or run ubuntu2204.exe which is a wrapper around the WSL API.

Yes, path translations should be manually customizable. That's why this issue is still open, after all! I'd rather have some progress than no progress.

[ParadoxV5]

Even these proposed solutions don't work for the case where you run wsl from within PowerShell, or run ubuntu2204.exe which is a wrapper around the WSL API.

Is it possible for the terminal to know what (sub)process it is currently hosting?

[DHowett]

Is it possible for the terminal to know what (sub)process it is currently hosting?

To an extent, yes :)

We have it on the books to track what we're hosting so that we can display better error messages and do profile matching. However, it'll break down for "opaque" remoting protocols like SSH and all of WSL (since processes on the Linux side don't present as processes on the Windows side) ☹️

Still, that's better than nothing!

[MichalPetryka]

Wouldn't it be enough to just introduce a separate "unixPaths": "true" setting for it for most usecases?

[ParadoxV5]

However, it'll break down for "opaque" remoting protocols like SSH and all of WSL (since processes on the Linux side don't present as processes on the Windows side) ☹️

Still, that's better than nothing!

At least enough for the terminal to know that it’s running something WSL!
(Probably not enough to know that it’s hosting a Linux through SSH, though.)

[driver1998]

We already use VT to let shells announce their CWD, why not use VT to let shells announce what they actually are?

[martin-eder-zeiss]

Wouldn't it be enough to just introduce a separate "unixPaths": "true" setting for it for most usecases?

This does not work in my case. I use WSL and Cygwin, which have different prefixes:

WSL: /mnt
Cygwin: /cygpath