fix(core): resolve Windows shells installed as app-execution aliases - #48968
Hotragn wants to merge 2 commits into
Conversation
Sorry, something went wrong.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: Potential Duplicate Found:
Why it's related: This PR has the exact same title and addresses the same issue (Windows Store/MSIX shell installations not being resolved). It appears to be a previous attempt at the same fix. You should verify whether #43323 is still open, closed, or merged, and consider whether this PR (48968) supersedes it or if there's redundant work being done. |
Sorry, something went wrong.
|
The needs:issue label looks like it was applied before the description was saved — the body does link the issue (Closes #41426, which is open). Happy to adjust the wording if the check wants a different format. |
Sorry, something went wrong.
|
Confirming the flag: #43323 is mine and is the same fix targeting dev. This one targets v2, which AGENTS.md on that branch asks PRs to default to, and it is not a cherry-pick — the resolution logic moved to shell/select.ts (executable()), so it needed porting. It also carries the review feedback from #43323: memoized lookups and an absolute path instead of a bare name. Happy to close #43323 in favour of this one if that's cleaner. |
Sorry, something went wrong.
Issue for this PR
Closes #41426
Type of change
What does this PR do?
A shell installed from the Microsoft Store — most commonly pwsh — is not found, so setting shell: "pwsh" silently falls back to Windows PowerShell 5.1.
Store/MSIX installs expose their executable as an app-execution alias: a zero-byte AppExecLink reparse point on PATH. CreateProcess resolves it by name, but stat reports nothing and which skips it. executable() in shell/select.ts resolves non-rooted names through which, so the shell comes back as "not installed" and selection moves on without telling the user.
Measured on a Windows 11 box, using winget (always an alias) as the probe:
where.exe does see aliases, so it distinguishes "installed as an alias" from "not installed". The fallback is scoped narrowly: win32 only, only for a name already in META, and only after which has failed — so it cannot make an unrelated or absent binary resolve.
This also looks like the root cause behind #30615 and #17372.
How did you verify your code works?
packages/core/test/shell.test.ts — 11/11 pass. Added a case asserting that a known-but-absent shell (zsh, ksh) still falls back rather than resolving to its own bare name, which is the regression this fallback could otherwise introduce. Verified where.exe returns 0 for an installed alias and 1 for an absent shell on the same machine.
Checklist