From 870499430b5ff9cd5d4d630130f656f5e6022450 Mon Sep 17 00:00:00 2001 From: HuanLinOTO Date: Tue, 8 Sep 2026 21:21:30 +0800 Subject: [PATCH] =?UTF-8?q?docs(terminal):=20resolveShellExecutable=20JSDo?= =?UTF-8?q?c=20=E8=B7=9F=E9=9A=8F=20shell-not-found=20=E6=96=B0=E9=94=99?= =?UTF-8?q?=E8=AF=AF=E7=A0=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/pty-manager.ts | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/pty-manager.ts b/src/pty-manager.ts index 88896de..6ea0014 100644 --- a/src/pty-manager.ts +++ b/src/pty-manager.ts @@ -336,8 +336,10 @@ function windowsPwshCandidateDirs(env: NodeJS.ProcessEnv): string[] { /** * Resolve the configured shell executable before handing it to node-pty. * - * POSIX node-pty uses `execvp`, so bare commands already follow PATH and are - * passed through unchanged. Windows' native backend does not consistently + * POSIX and Windows are both probed BEFORE spawn so a wrong configured name + * becomes a stable, actionable `shell-not-found` error instead of a bare + * "[process exited with code N]" (POSIX execvp) or an opaque native string + * (Windows). Windows' native backend additionally does not consistently * apply the shell's PATHEXT lookup to a bare value (`pwsh` / `cmd` can fail * with the opaque `File not found:` error), so perform the lookup ourselves: * @@ -345,8 +347,8 @@ function windowsPwshCandidateDirs(env: NodeJS.ProcessEnv): string[] { * suffix when the user omitted `.exe`), * - a bare name is searched through PATH, System32, and PowerShell's known * install directories, - * - failure becomes a stable, actionable pty-error instead of a native - * backend string with no mention of the configured shell. + * - failure becomes a stable, actionable `shell-not-found` error instead of + * a native backend string with no mention of the configured shell. */ export function resolveShellExecutable( shell: string,