Support configuring the local terminal launched in remote windows

My workflow requires compilation in Linux, but running the produced artefact in Windows. This requires me constantly jumping between a whole variety of terminals, and is very inconvenient. Currently there are numerous bits of disparate support for host shells and terminals when using remotes, but none of the solutions seem to actually work properly. This is especially evident when it comes to tasks.

My current approach involves using the WSL remote, with the following configuration. Local terminals seem to have been added to the terminal dropdown with the WSL extension, due to the following being automatically added to my user settings;

"terminal.integrated.profiles.linux": {
    "PowerShell (WSL Host)": {
        "path": "/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe",
        "icon": "terminal-powershell"
    },
    "Command Prompt (WSL Host)": {
        "path": "/mnt/c/Windows/System32/cmd.exe",
        "icon":"terminal-cmd"
      }
}

Since WSL automatically mounts all windows drives, these paths seem to work correctly. These terminals seem to be running from the host, so any commands run are executed as the host PC rather than the WSL instance. This is useful, and allows running commands from both the WSL instance and the host. However, this seems to be a workaround exclusive to WSL due to it’s automatic mounting of the windows drives and doesn’t work for container remotes.

When opening the command palette, there are two interesting commands - Terminal: Create New Terminal (In Active Workspace) and Terminal: Create New Terminal (Local). The first seems to open a new terminal in the same manner as Ctrl+Shift+', however the second is extremely weird and I can’t find much documentation on it. It seems to open a local powershell on windows, but there’s no configuration for it.

It’s not possible to add this terminal to terminal.integrated.profiles.linux to add it to the terminal choice dropdown, since it seems to be entirely separate to the rest of the terminal functionality and settings. It’s also not possible to use this shell in any sort of tasks, since again it doesn’t exist as a terminal profile and seems to be it’s own separate thing.

Ultimately, there seems to be extremely inconsistent and unintuitive support for using the host shell, and it varies by the type of remote you’re using. In addition, there seems to be little documentation on this, so what is actually possible is extremely vague. To try and make this a bit more consistent, I suggest the following;

• Expose the shell created by Terminal: Create New Terminal (Local) as a source to add to terminal.integrated.profiles.*, allowing it to be added to the shell dropdown and selected as the default.
• Add the ability to configure the local shell that is opened with Terminal: Create New Terminal (Local).

This should ultimately allow something like;

settings.json

"terminal.integrated.profiles.linux": {
    "bash":{
        "path": "/bin/bash",
        "icon": "terminal-bash"
    },
    "PowerShell (Local)": {
        "source": "local",
        "icon": "terminal-powershell"
    }
},
"terminal.integrated.defaultProfile.linux": "bash",

"terminal.intergrated.profiles.local": {
    "PowerShell":{
        "path": [
            "${env:windir}\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
        ],
        "icon": "terminal-powershell"
    }
}
"terminal.integrated.defaultProfile.local": "PowerShell",

This would make using local shells as easy as using remote shells. This would greatly improve the usability of Container remotes, and get rid of the hacky workarounds that are necessary for WSL remotes.

[Jademalo]

Alright, that all seems reasonable. I’ll split off the stuff associated with automation into a separate ticket, with how intertwined all of the systems are I wasn’t exactly sure what was right to split. I’ll also create a bug for the WSL local terminal issue, since that definitely seems strange.

[melink14]

I wanted my local terminal to be WSL when opening from Codespaces as well. I thought setting terminal.integrated.profiles.windows with a wsl path and making it the defaultProfile would work but it seems to be ignored.