Use PowerShell call operator when shell integration is unavailable

[owevertonguedes]

Closes #14583

Problem

When "Run C/C++ File" targets a terminal without shell integration, launchIntegratedTerminal falls back to buildShellCommandLine(...) + terminal.sendText(...). That fallback quotes a program path containing spaces but never prepends the PowerShell call operator, so PowerShell evaluates the quoted path as a string literal and echoes it back instead of executing the program:

PS C:\...\00 - Test> "C:\...\00 - Test\main.exe"
C:\...\00 - Test\main.exe

This matches the reported output exactly: had the shell-integration path run, the command would have been rendered as & "C:\...\main.exe".

The shell-integration path already handles PowerShell correctly (added in #14351), but its detection logic was inline and therefore unavailable to the fallback. buildShellCommandLine also carries an explicit // TODO: Support launching with PowerShell.

Change

• Extract the existing PowerShell detection into a isPowerShellTerminal() helper (behavior unchanged, including the "assume PowerShell on Windows when the shell is unknown" fallback).
• Reuse it in the sendText path to prepend & for PowerShell.

No behavior change for cmd.exe or POSIX shells, or for terminals that do have shell integration.

Testing

• tsc --noEmit passes for the changed file, and eslint is clean.
• The existing runWithoutDebugging.terminals.test.ts matrix already covers a spaced executable across the undefined / Command Prompt / PowerShell profiles, but it only exercises the shell-integration path, which is why this fallback regressed unnoticed.

I could not exercise the Windows/PowerShell fallback end-to-end (no Windows machine available), so I would appreciate a careful look at that path in review.

[owevertonguedes]

@microsoft-github-policy-service agree

[bobbrow]

@owevertonguedes, so are there versions of PowerShell that do not support shell integration, or is there some VS Code bug where it fails to activate? The code changes look reasonable, but I'd like to understand the case where shell integration doesn't work with PowerShell.

[Copilot]

Pull request overview

This PR fixes “Run C/C++ File” on PowerShell terminals when shell integration is unavailable by ensuring the command is invoked with the PowerShell call operator so spaced executable paths are executed rather than echoed.

Changes:

• Extracts PowerShell terminal detection into a reusable isPowerShellTerminal() helper.
• Reuses that helper in the no-shell-integration fallback to prefix commands with & for PowerShell.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[owevertonguedes]

Thanks for the review. Honest answer: I can't tell you for certain why shell integration wasn't available in the reporter's case — the issue doesn't include that diagnostic, and I wasn't able to reproduce it myself (I don't have a Windows/PowerShell environment).

What the code does tell us: the reported output (a quoted path echoed back, no &) is what the sendText fallback produces today. The shell-integration path prepends & for PowerShell, so had it run, the program would have executed. That output is what pointed me to the fallback, which is why the change is scoped to that branch specifically.

What I can't tell you is which of the two cases you're describing this was:

• a PowerShell setup where shell integration is legitimately unavailable (execution policy blocking the injection script, a custom profile, an older version), or
• a case where it should have activated but didn't within the 3-second wait that precedes the fallback.

The reporter's shell-integration diagnostics would most likely separate these two, but I don't want to over-scope the PR.

What this change does in either case: the sendText fallback already exists and is reachable whenever shell integration isn't present, and today it produces an invalid command on PowerShell. This makes that fallback run the program correctly regardless of why it was reached — so "Run C/C++ File" works again in the reported scenario. Whether the activation question is worth a separate look is your call.