Non-WSL paths should be linkified in WSL terminals

[sgtz]

• VSCode Version: 1.37.1
• OS Version: Win10

Steps to Reproduce:

1. start WSL in a VS Code terminal
2. echo "C:\a\b\c.txt:14"
3. Ctrl+Mouse hover over text, and it won't be noticed by VS Code

-- steps to reproduce are incorrect. The text probably needs to go through standard error.

AI initially started VS Code from the WSL command line. Option to reopen at startup look like "Abc [WSL] /c"

I did just see this working via Start/search bar/code.

If you do the same from cmd.exe VS Code terminal window, VS Code will work as expected. Note: a path like /c/a/b/c.txt:14 will be recognised. The problem is that certain toolchains still know they're on windows, and will display errors with a back-slash+c: path style. It is nice to be able to work 100% in bash for consistency with target servers.

It's looking like only people using https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl will come across this issue.

... if you run cmd.exe from VS Code session initiated by WSL, and then fire off said toolchain, path patterns still fail to be recognised.

Does this issue occur when all extensions are disabled?: Yes, but WSL compatibility caused the issue. ie. (guessing again) VS Code starts stores config / session / temporary data using subsystem conventions (in this case Ubuntu). I like that. It's just that this assumption is incorrect in the case above (a toolchain runs on WSL but errs towards Windows path conventions on standard error, 'cause it knows).

[weinand]

I suggest that you use the WSL extension: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

[sgtz]

@weinand thanks, but I already had that installed. Probably that's how I got in this mess in the first place. I do like starting VS Code from WSL. I'll have to amend my ways.

[aeschli]

@sgtz Can you add a screenshot that shows the terminal? What I need to know, are you in a remote WSL window or not?

[sgtz]

@aeschli: definitely not in remote WSL. It's a local session.

I would tend to start VS Code like this:

staylor@ABC123:~$ alias code
alias code='code'
staylor@ABC123:~$ cd /c/some_dev_dir
staylor@ABC123:~$ code .

for some reason WSL likes code to be quoted.

Another issue?

staylor@ABC123:/c/d$ chmod 700 /home/staylor/.ssh/id_rsa

staylor@ABC123:/c/d$ git push
@@@@@@@@@@@@@@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/staylor/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/staylor/.ssh/id_rsa": bad permissions
git@ABC.org: Permission denied (publickey).
fatal: Could not read from remote repository.

The temporary? solution is to use gitbash.

[sgtz]

@aeschli: this is an example of it working from a non WSL terminal

[aeschli]

@sgtz Sorry, please help me more by giving detailed steps

    staylor@ABC123:~$ alias code
    alias code='code'
    staylor@ABC123:~$ cd /c/some_dev_dir
    staylor@ABC123:~$ code .

Where do you enter this? WSL shell? Integrated terminal in a local VSCode run on wsl.exe?

The purpose of the Remote - WSL extension is exactly to enable you to call code . in a WSL shell. It opens a 'Remote' VSCode window where the full VSCode backend runs inside WSL. Running wsl in a local VSCode windows is not longer recommended.

See https://code.visualstudio.com/docs/remote/wsl#_open-a-folder-in-wsl

[sgtz]

... is this a big change request? It's probably just a question of making Std Error work as it should. It'd still be a really nice feature for Terminal. P.S. I currently use a mac book pro to get this feature out of a terminal using VS Code ;). As I use multiple environments, with strict lockdown at work (no Mac), it'd be awesome to have this work consistently. Anyone who works from the cmd line would be affected who interacts with a compiler's output.

[Tyriar]

Yes it is more difficult to fix than you might expect due to the architecture of remote and how the links in the terminal work. The main problem is that the client doesn't know about how WSL works and adding that detection in core would be hack/circular dependency which would be best to avoid (core <-> remote-wsl), the links are all validated on the remote server side and that is just a Linux machine to the terminal.

FYI @aeschli both of the following cases are probably on the WSL extension side to support unless you have better ideas:

1. Non-WSL links working in Remote-WSL sessions: The Remote-WSL extension could register a terminal link providers for links like c:\....
2. WSL links inside non-Remote-WSL sessions: The Remote-WSL extension could also register a terminal link provider here conditionally based on the terminal's shell (when wsl.exe, etc.), I don't know when/if the Remote-WSL extension could be activated in local workspaces. Perhaps this should be built into core using electron-sandbox?

I'll reopen and move to the remote repo for more discussion as I believe this is an issue more on the extension side.

[aeschli]

Sorry I'm still confused. Are you in a remote WSL window or not? Can you add reproducible steps that show the problem, so I don't need to guess? Add a screenshot of the whole window and show where you expect a link and what it should do?

[sgtz]

It wasn't in remote WSL mode. Regular WSL. It'd be great if it worked on remote WSL as well. Go for it! I'd be happy with just windows. I can't get a screenshot for you at the moment due to the security concerns of our risk partners. They will roll it out eventually. My recent compromise was git bash / PowerShell. Links published via StdError work well in PowerShell when clicked. They have worked in git bash... but just not currently. Windows Terminal + WSL is much nicer to work with. I'd rather not also have Powershell in the mix. I'd prefer WSL for consistency across servers + desktops if possible.

[aeschli]

ok, thanks for the information, that clarifies things. So baiscally you ask for WSL aware link detectors

• in local windows (when in a WSL shell) handle links like /mnt/c/..
• in WSL windows handle links like c:\asds\