/cc @DonJayamanne

Why?

The reason we need this is because the default for terminal.integrated.shell.* became null in 1.35 in order to get default shell detection working for remote scenarios.

Proposal

export namespace window {
	/**
	 * The detected default shell for the extension host, this is overridden by the
	 * `terminal.integrated.shell` setting for the extension host's platform.
	 */
	export const shell: string;
}

The fix I'm proposing is to have an window.shell exposed which will return the exact shell that would be launched by opening a terminal, that way extensions can launch terminals like createTerminal({ shellPath: window.shell }). I thought about using env.shell but that would be away from the rest of the terminal options, plus this value can differ between windows.

Alternatives considered

As for alternatives, I looked into registering the setting with the default shell on start up, then having the ext host send the correct shells and deregistering/registering the setting again with the new default. This approach has problems though:

• Terminals restored on start up in remote workspaces will launch with the local default, not the remote one.
• Using local Uris as the cwd in the terminal will not use the correct local default shell

Related issues

• The original discussion Shell information no longer returned in settings #74233
• The python issue/workaround Terminal not getting activated in Insiders vscode-python#5743
• vscode-maven discussion Generate from archetype fails on Windows if default shell is not explicitly set. vscode-maven#337