Can't open external terminals by default from a WSL session in VS Code

[Tyriar]

When debugging using an external terminal from WSL you see this:

It ends up calling the Linux exec setting:

Ref:

vscode/src/vs/platform/externalTerminal/node/externalTerminalService.ts

Line 228 in 2fa61a1

termArgs.push('-e');

Is there some way we can route WSL debug requests to a local external terminal? @aeschli thoughts on this? Do you think this should be handled somehow in the WSL extension? Feels like the a soft layer breaker if it goes into core.

cc @shanselman

[roblourens]

In the Slack thread, @aeschli pointed out the WSL_DISTRO_NAME environment var. I think it doesn't feel too bad just for us to read that to determine that the remote EH is inside WSL

[connor4312]

microsoft/vscode-remote-release#45 is related as well. Maybe we have something generic in for remotes in core?

[aeschli]

If there's a contribution point or a env variable I can set in the WSL extension. That would be the cleanest way.

[Tyriar]

Unassigning Rob again, I think I'm doing all the work here, just might need a review/help from others.

[Tyriar]

Debugging with Windows Terminal also doesn't seem to work when these are set:

  "terminal.external.windowsExec": "wt",
  "terminal.external.windowsExec": "wt.exe",

[Tyriar]

We explicitly support spawning a terminal:

vscode/src/vs/platform/externalTerminal/node/externalTerminalService.ts

Lines 62 to 65 in 1d342c9

	// Add starting directory parameter for Windows Terminal (see #90734)
	if (basename === 'wt' || basename === 'wt.exe') {
	cmdArgs.push('-d .');
	}

Not debug's runInTerminal:

vscode/src/vs/platform/externalTerminal/node/externalTerminalService.ts

Lines 78 to 85 in 1d342c9

	return new Promise<number | undefined>((resolve, reject) => {
	const title = `"${dir} - ${TERMINAL_TITLE}"`;
	const command = `""${args.join('" "')}" & pause"`; // use '|' to only pause on non-zero exit code
	const cmdArgs = [
	'/c', 'start', title, '/wait', exec, '/c', command
	];

[Tyriar]

I don't think it's possible to use wt properly based on --help, no /c, no --wait 🤔

[Tyriar]

Actually /c is SUBCOMMAND, eg. wt "cmd.exe"

[gregg-miskelly]

I very similar issue exists for Codespaces where the runInTerminal request will fail, and it isn't obvious to users that that is the problem. Would you like me to open a new issue? Or would this issue track all remoting scenarios?

CC @timheuer who reported this to me

[Tyriar]

I had a go trying to fix this but it was more difficult than anticipated: #171095

[vs-code-engineering]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!