API to access the shell type for a given terminal

[karthiknadig]

Currently there is no API available on the terminal that allows extensions to detect the shell type. This is needed for Python where there are shell specific activation scripts.

[gjsjohnmurray]

Does #127374 (comment) point to a way?

[karthiknadig]

@gjsjohnmurray That is not available to Terminals created using ExtensionTerminalOptions.

[gjsjohnmurray]

There isn't a universal concept of "shell type" for a terminal contributed by an extension. However it's possible to define your own interface that extends ExtensionTerminalOptions so it can hold other properties that get set when the extension terminal gets created. These extra properties will be present in Terminal.creationOptions when a terminal is fetched from window.activeTerminal or window.terminals[]

[karthiknadig]

@gjsjohnmurray There is a terminalShellType context that is set for terminals, it should likely be set as a property on the terminal itself.

vscode/src/vs/platform/terminal/common/terminal.ts

Line 149 in b2f1498

export type TerminalShellType = PosixShellType | WindowsShellType | GeneralShellType;

vscode/src/vs/workbench/contrib/terminal/common/terminalContextKey.ts

Line 85 in b2f1498

export const shellType = new RawContextKey<string>(TerminalContextKeyStrings.ShellType, undefined, { type: 'string', description: localize('terminalShellTypeContextKey', "The shell type of the active terminal, this is set if the type can be detected.") });

The issue is that, when any extension or VS Code creates a terminal (DAP run-in-terminal for example) or the user click on the ➕ button to create terminals there is no consistent way to detect what shell it is using by examining the terminal instance. I understand that the shell type is a transient thing in a terminal. But, to provide better experience we need to know what it is at that moment for the terminal.

For Python extension, we need this for terminals created from any source, not just from python extension. The reason we need it is so we can configure the terminal to use the right python and packages from the correct locations. Typically, this is done by running a script provided by the python environment. These scripts are shell specific, and without this detail it leads to a bad terminal experience if we can't configure the environment correctly.

Currently we detect shells is by using the Terminal.name on terminal creation. This is limiting because, when some other source like DAP creates it that name is not set to the shell type, and that breaks detection. In cases where user clicks the ➕ the name is set to shell type.

[Tyriar]

@gjsjohnmurray we have some detection internally based on various factors like process name, executables in the process tree, etc. Exposing that would work for terminals created via extensions too, as long as they are backed by an executable, not a Pseudoterminal API object.