OrcaWin
1f37e5ac54
#6967 derived the Windows setup-runner shell from `terminalWindowsShell`. On upgrade, any Windows user whose terminal preference resolved to Git Bash had their existing `orca.yaml` setup script (and issue command) handed to bash instead of cmd.exe. Scripts authored against the cmd runner — `copy`, `xcopy`, `set VAR=value`, `if errorlevel 1`, `%VAR%`, backslash paths — broke with no migration and no warning, and the failure looked like Orca broke the project. The conflation is also wrong in the steady state: a terminal preference is per-user, so two people on the same repo got different interpreters for the same orca.yaml and no project could write a setup script that worked for all of its Windows contributors. The interpreter is now a property of the script, declared the standard way: a leading `#!` line. Native Windows keeps the historical `.cmd` runner unless the script declares a POSIX shell, so no existing script changes behavior. `resolveSetupRunnerShell` keeps its role as the feasibility gate — a bash runner still requires the terminal to resolve to Git Bash, since the launch command is typed into that shell and uses MSYS `/c/...` paths. `buildWindowsRunnerScript` now drops a leading `#!` line rather than `call`ing it, so a declared-bash script that falls back to cmd (Git Bash missing) fails on a real setup line instead of aborting on errorlevel at line one. WSL worktrees, POSIX platforms, and SSH hosts are untouched.
2.0 KiB
Windows setup-runner shell
On native Windows, Orca writes the orca.yaml setup script (and the issue command) to a generated
runner file and types a launch command into a terminal. The runner is a .cmd batch file by
default, exactly as it has been since setup hooks shipped.
A script opts into bash by starting with a #! interpreter line:
scripts:
setup: |
#!/usr/bin/env bash
[ -f .env ] || cp .env.example .env
pnpm install
Without that line the script keeps running under cmd.exe:
scripts:
setup: |
copy .env.example .env
xcopy /E assets dist
Why the script declares it, not the terminal preference
terminalWindowsShell says which shell interactive terminals open in. It says nothing about the
language a project's setup script is written in. Deriving the runner from it had two consequences:
- Windows users with batch-syntax setup scripts silently switched to bash on upgrade, so
copy,xcopy,set VAR=value, andif errorlevel 1stopped working. - Two people on the same repo got different interpreters for the same
orca.yaml, so no project could write a setup script that worked for all of its Windows contributors.
A #! line is per-project, explicit, and identical for everyone who checks the repo out.
Requirements for the bash runner
A #! line only takes effect when Orca can actually launch bash from the configured terminal — the
terminal shell must resolve to Git Bash (resolveWindowsGitBashShellPath). The generated runner
uses MSYS /c/... paths, which Cygwin and the WSL shim do not accept, and the launch command is
typed into whatever shell the terminal opened with. When Git Bash is not available the script falls
back to the .cmd runner; the #! line is dropped rather than executed.
WSL worktrees and non-Windows platforms are unaffected: they always use the bash runner. SSH hosts choose their runner from the remote path format, never from local Windows preferences.