[Query] Can you add a WSL installed version of PowerShell Core as a session option on Windows?

[kilasuit]

The scenario (which may/maynot be possible) would be to have VSCode on Windows be able to add in a WSL session of PowerShell Core on Windows machines

This assumes

• WSL feature is installed

• Ubuntu image installed

• Pwsh installed in Ubuntu WSL

If this were possible then that would help local xplat development in VSCode eve further than currently

[kilasuit]

My initial thoughts are that this should be able to be surfaced using the powerShellAdditionalExePaths setting?

[rjmholt]

The powershellAdditionalExePaths would be the right place. It looks like you can call any WSL executable by passing it as a parameter to wsl.exe, so if the additional exe paths feature supports that, then that would be the way to go.

Otherwise, we should invest in something similar to #1470.

My only concern would be allowing arbitrary commands to be executed in configurations - we would need to manage that carefully.

But I would imagine the best way to find out is to play with it a bit

[rkeithhill]

Well, starting pwsh in WSL is only part of what's needed. I don't "think" Windows pipes work as an interop mechanism between Windows and WSL, so we'd have to provide an option to use the old TCPIP sockets IPC. Or maybe use domain sockets between Windows and WSL - https://blogs.msdn.microsoft.com/commandline/2018/02/07/windowswsl-interop-with-af_unix/

[kilasuit]

So I have set up the following in my settings

"powershell.powerShellAdditionalExePaths":  [ {
        "versionName":"WSL-Ubuntu",
        "exePath": "C:\\WINDOWS\\system32\\wsl.exe /opt/microsoft/powershell/6/pwsh"
    },
    {
        "versionName":"WSL-Ubuntu-Path",
        "exePath": "C:\\WINDOWS\\system32\\wsl.exe"
    },
    {
        "versionName":"DockerImage",
        "exePath": "C:\\Program Files\\Docker\\Docker\\Resources\\bin\\docker.exe run -it microsoft/powershell"
    }
    ],

when I try to open the WSL-Ubuntu or DockerImage sessions it seems to try loading them and then fails and reverts back to default PowerShell session with the below in the logs.

9/28/2018 8:59:30 AM [NORMAL] - Visual Studio Code v1.27.2 64-bit
9/28/2018 8:59:30 AM [NORMAL] - PowerShell Extension v1.8.4
9/28/2018 8:59:30 AM [NORMAL] - Operating System: Windows 64-bit
9/28/2018 8:59:30 AM [NORMAL] - Path specified by 'powerShellExePath' setting - 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run -it microsoft/powershell' - not found, reverting to default PowerShell path.
9/28/2018 8:59:30 AM [NORMAL] - Language server starting --
9/28/2018 8:59:30 AM [NORMAL] -     exe: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
9/28/2018 8:59:30 AM [NORMAL] -     args: C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '1.8.4'-AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules'-EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\logs\1538121570-1d5f6bf0-fc93-40d6-8e83-a767fa8140f31538121561775\EditorServices.log' -SessionDetailsPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\sessions\PSES-VSCode-7112-175093' -FeatureFlags @()
9/28/2018 8:59:30 AM [NORMAL] - Syntax Folding Provider registered
9/28/2018 8:59:33 AM [NORMAL] - Language server started.
9/28/2018 8:59:33 AM [NORMAL] - {"status":"started","debugServiceTransport":"NamedPipe","languageServiceTransport":"NamedPipe","debugServicePipeName":"\\\\.\\pipe\\PSES_34aa6310-7088-4a53-94b8-d52475a62b35","languageServicePipeName":"\\\\.\\pipe\\PSES_057985a6-5a2a-48a5-9475-4ea31c003836"}
9/28/2018 8:59:33 AM [NORMAL] - Connecting to language service on pipe \\.\pipe\PSES_057985a6-5a2a-48a5-9475-4ea31c003836...
9/28/2018 8:59:33 AM [NORMAL] - Language service connected.
9/28/2018 8:59:34 AM [NORMAL] - powershell.exe started, pid: 20108
9/28/2018 8:59:38 AM [NORMAL] - Shutting down language client...
9/28/2018 8:59:38 AM [NORMAL] - Terminating PowerShell process...
9/28/2018 8:59:38 AM [NORMAL] - Path specified by 'powerShellExePath' setting - 'C:\WINDOWS\system32\wsl.exe /opt/microsoft/powershell/6/pwsh' - not found, reverting to default PowerShell path.
9/28/2018 8:59:38 AM [NORMAL] - Language server starting --
9/28/2018 8:59:38 AM [NORMAL] -     exe: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
9/28/2018 8:59:38 AM [NORMAL] -     args: C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '1.8.4'-AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules'-EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\logs\1538121578-1d5f6bf0-fc93-40d6-8e83-a767fa8140f31538121561775\EditorServices.log' -SessionDetailsPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\sessions\PSES-VSCode-7112-675313' -FeatureFlags @()
9/28/2018 8:59:39 AM [NORMAL] - powershell.exe started, pid: 10256
9/28/2018 8:59:40 AM [NORMAL] - Language server started.
9/28/2018 8:59:40 AM [NORMAL] - {"status":"started","debugServiceTransport":"NamedPipe","languageServiceTransport":"NamedPipe","debugServicePipeName":"\\\\.\\pipe\\PSES_7993a509-c6fc-4849-bfd3-7285cadd9183","languageServicePipeName":"\\\\.\\pipe\\PSES_3f6d9ca4-a60c-4a3d-9f39-d178d4b4e339"}
9/28/2018 8:59:40 AM [NORMAL] - Connecting to language service on pipe \\.\pipe\PSES_3f6d9ca4-a60c-4a3d-9f39-d178d4b4e339...
9/28/2018 8:59:40 AM [NORMAL] - Language service connected.
9/28/2018 9:12:54 AM [NORMAL] - Shutting down language client...
9/28/2018 9:12:54 AM [NORMAL] - Terminating PowerShell process...
9/28/2018 9:12:54 AM [NORMAL] - Path specified by 'powerShellExePath' setting - 'C:\WINDOWS\system32\wsl.exe /opt/microsoft/powershell/6/pwsh' - not found, reverting to default PowerShell path.
9/28/2018 9:12:54 AM [NORMAL] - Language server starting --
9/28/2018 9:12:54 AM [NORMAL] -     exe: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
9/28/2018 9:12:54 AM [NORMAL] -     args: C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '1.8.4'-AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules'-EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\logs\1538122374-1d5f6bf0-fc93-40d6-8e83-a767fa8140f31538121561775\EditorServices.log' -SessionDetailsPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\sessions\PSES-VSCode-7112-201235' -FeatureFlags @()
9/28/2018 9:12:55 AM [NORMAL] - powershell.exe started, pid: 2024
9/28/2018 9:12:56 AM [NORMAL] - Language server started.
9/28/2018 9:12:56 AM [NORMAL] - {"status":"started","debugServiceTransport":"NamedPipe","languageServiceTransport":"NamedPipe","debugServicePipeName":"\\\\.\\pipe\\PSES_90950b52-217e-40e4-9c2b-6dabab4bc09a","languageServicePipeName":"\\\\.\\pipe\\PSES_50d7545f-cf09-4f82-a643-89f482e0a2a2"}
9/28/2018 9:12:56 AM [NORMAL] - Connecting to language service on pipe \\.\pipe\PSES_50d7545f-cf09-4f82-a643-89f482e0a2a2...
9/28/2018 9:12:56 AM [NORMAL] - Language service connected.
9/28/2018 9:13:00 AM [NORMAL] - Shutting down language client...
9/28/2018 9:13:00 AM [NORMAL] - Terminating PowerShell process...
9/28/2018 9:13:00 AM [NORMAL] - Language server starting --
9/28/2018 9:13:00 AM [NORMAL] -     exe: C:\WINDOWS\system32\wsl.exe
9/28/2018 9:13:00 AM [NORMAL] -     args: C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules\PowerShellEditorServices\Start-EditorServices.ps1 -HostName 'Visual Studio Code Host' -HostProfileId 'Microsoft.VSCode' -HostVersion '1.8.4'-AdditionalModules @('PowerShellEditorServices.VSCode') -BundledModulesPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\modules'-EnableConsoleRepl -LogLevel 'Normal' -LogPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\logs\1538122380-1d5f6bf0-fc93-40d6-8e83-a767fa8140f31538121561775\EditorServices.log' -SessionDetailsPath 'C:\Users\ryan\.vscode\extensions\ms-vscode.powershell-1.8.4\sessions\PSES-VSCode-7112-926887' -FeatureFlags @()
9/28/2018 9:13:01 AM [NORMAL] - powershell.exe started, pid: 16580
9/28/2018 9:13:01 AM [NORMAL] - powershell.exe terminated or terminal UI was closed
9/28/2018 9:15:00 AM [NORMAL] - Language server startup failed.
9/28/2018 9:15:00 AM [ERROR] - The language service could not be started: 
9/28/2018 9:15:00 AM [ERROR] - Timed out waiting for session file to appear.

When I try calling the WSL-Ubuntu-path session I do get a pop up saying The terminal process terminated with exit code 2

I'm speculating here, but I think this looks more and more likely this might not be able to be done all that easily.

[SeeminglyScience]

From what I can tell, the exePath can't take any arguments.

Also, I really don't think it would be this easy. Here's some concerns/questions I have directed at no one in particular, just food for thought.

1. Would the server create a Linux pipe when the client is expecting a Windows pipe?
2. How would permissions need to be set up for said pipe? Could we even configure a pipe in such a way that the client could connect to it without the pipe being 100% open?
3. Would file system paths need to be translated? If the client is telling the server about C:\projects\script.ps1, would that need to be translated to /mnt/c/projects/script.ps1? Maybe a source map type system?

I could be totally off base and all of these concerns could be invalid, but if they aren't, then it would be a non-trivial amount of development to get this working. (Not saying it won't or shouldn't happen, only that I doubt this will be a simple config change)

[rkeithhill]

Yeah, I think we'd have to resurrect the TCPIP/sockets IPC mechanism for this and we'd have to add support for arguments for the powershell.powerShellAdditionalExePaths setting. In my case, I have several Linux distros installed so I'd need to be able to specify which distro as well as pwsh or pwsh-preview. And we'd have to add an option to request starting PSES using TCPIP. And yeah, there's the source path mapping issue. You can't even assume C: -eq /mnt/c because WSL allows you config that. We could default to that mapping but there'd have to be a field to specify the workspace folder path from the WSL perspective. There is a utility to do the path conversion wslpath but it's relatively new (1803?) so we probably couldn't rely on it. The bigger trick is managing all these path conversions within PSES.

[rjmholt]

Seems like another good case for bringing back TCP connections to me :)

[kilasuit]

It sounds like this would be a headache to get implemented.

However if it were to be able to happen then it would be an awesome addition especially for xPlat testing

[TylerLeonhardt]

Today you can get this to work by double checking the ssh server is running on wsl and then use PowerShell Remoting over ssh.

This would also work for containers

[TylerLeonhardt]

FYI, this was broken pre-1.10.0 but now we handle local remoting sessions better. Here's a screenshot of editing a script from WSL:

Steps:

1. Install PowerShell Core in WSL
2. Setup PowerShell remoting over ssh
3. I had to run sudo ssh-keygen -A to recreate default keys
4. Optionally change the Port in your sshd_config to something like 5522 (don't forget to restart ssh again)
5. In the PowerShell Integrated Console - simply do:

Enter-PSSession -Hostname username@localhost:5522

From here you can use *-EditorFile and debug any scripts.

I think this is a reasonable experience for WSL and containers. We can rely on PowerShell Remoting to do the right thing here.

Gonna close this for now, please let me know if you feel otherwise.