mirror of
https://github.com/stablyai/orca.git
synced 2026-09-23 00:02:29 +00:00
* fix(worktrees): stop silently switching existing Windows setup scripts to Git Bash #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. * fix(worktrees): keep the cmd setup runner launchable from a Git Bash pane Adversarial review of this PR found that pinning the runner format per script reopened issue #6896 one layer down. - `WorktreeSetupLaunch.shell` had been redefined to mean "the format the runner file was written in". `resolveSetupRunnerCommand` consumes it as "the shell that types the launch command", so a Git Bash terminal with a batch setup script produced `cmd.exe /c "C:\...\setup-runner.cmd"` typed into a bash pane, where MSYS rewrites the `/c` switch into a drive path: cmd opens interactively and setup never runs. `shell` is the terminal's family again; the runner file's .cmd/.sh extension carries the format, and a batch runner launched from a POSIX pane reuses the existing PowerShell ProcessStartInfo launcher. - The cmd runner dropped a leading `#!` line and ran the rest as batch, so a bash script reaching cmd (PowerShell/cmd terminal, or any SSH-to-Windows host) got its interpreter-agnostic prefix executed before failing mid-way. It now prints why and exits 1 without running anything. - A `#!` line's option flags were discarded: `#!/usr/bin/env -S bash -euo pipefail` lost pipefail because the runner is launched as `bash <path>`. The generated posix runner now replays declared flags via `set` and drops the duplicate interpreter line. - Docs cover the per-user setup command in repository hook settings, which goes through the same `#!` rule, and describe what the `#!` line does and does not select. Tests: composed launch command for a POSIX pane + cmd runner (hooks, shared runner command, setup sequencing gate, observed-setup signal), the cmd runner's shebang refusal, and shebang flag replay. Each fails with the source reverted. * fix(worktrees): replay only real `set` flags and keep the gate in the pane's shell Two round-2 review findings: - `#!/bin/bash -l` replayed `set -l`, which exits 2 and aborted the runner under its own `set -e` before a single setup line ran (all platforms). Only the flags `set` documents are replayed now; a bare `-o` with no option name is dropped instead of dumping the shell-option table. - The wait-for-setup gate picked its language from the runner file, so a batch runner launched from a Git Bash pane got the PowerShell gate while the agent startup command was already POSIX-quoted — `Invoke-Expression` cannot parse `'\''`. The gate now follows the pane; the runner still launches through the ProcessStartInfo launcher, never through bash. --------- Co-authored-by: OrcaWin <293788423+OrcaWin@users.noreply.github.com>
101 lines
3.6 KiB
TypeScript
101 lines
3.6 KiB
TypeScript
// Why: the interpreter a setup/issue-command script is written for is a property of the script,
|
|
// not of the user's terminal preference, so a `#!` line is how a project declares it.
|
|
|
|
const POSIX_SHELL_BASENAMES = new Set(['sh', 'bash', 'zsh', 'dash', 'ksh', 'ash'])
|
|
// Why: only the letters `set` itself accepts (`set [--abefhkmnptuvxBCHP] [-o option]`). An
|
|
// invocation-only flag such as `-l` or `-r` makes `set` exit 2, which under the runner's `set -e`
|
|
// aborts setup before its first line runs.
|
|
const SET_OPTION_FLAG_PATTERN = /^[-+][abefhkmnptuvxBCHP]+$/
|
|
// Why: `-o`/`-euo` name their option in the next token; a trailing `-o` with no name would make
|
|
// `set` dump the whole shell-option table into the setup terminal instead.
|
|
const SET_LONG_OPTION_FLAG_PATTERN = /^[-+][abefhkmnptuvxBCHP]*o$/
|
|
const SHELL_OPTION_NAME_PATTERN = /^[a-z_]+$/
|
|
|
|
export type SetupScriptShebang = {
|
|
/** Lowercased interpreter basename, e.g. `bash` for `#!/usr/bin/env -S bash -e`. */
|
|
interpreter: string
|
|
/** Interpreter flags the generated runner replays through `set`, e.g. `['-euo', 'pipefail']`. */
|
|
shellOptions: string[]
|
|
}
|
|
|
|
/** True when `line` is a `#!` interpreter line (leading whitespace tolerated). */
|
|
export function isShebangLine(line: string): boolean {
|
|
return line.trimStart().startsWith('#!')
|
|
}
|
|
|
|
/** Parses the script's leading `#!` line, or null when it has none. */
|
|
export function parseSetupScriptShebang(script: string): SetupScriptShebang | null {
|
|
const firstLine = script.split('\n', 1)[0] ?? ''
|
|
if (!isShebangLine(firstLine)) {
|
|
return null
|
|
}
|
|
|
|
const tokens = firstLine.trim().slice(2).trim().split(/\s+/).filter(Boolean)
|
|
const interpreterIndex = findInterpreterIndex(tokens)
|
|
if (interpreterIndex === -1) {
|
|
return null
|
|
}
|
|
|
|
return {
|
|
interpreter: executableBasename(tokens[interpreterIndex]),
|
|
shellOptions: parseShellOptions(tokens.slice(interpreterIndex + 1))
|
|
}
|
|
}
|
|
|
|
/** True when the script's first line is a `#!` line naming a POSIX shell. */
|
|
export function scriptDeclaresPosixShell(script: string): boolean {
|
|
const shebang = parseSetupScriptShebang(script)
|
|
return shebang !== null && POSIX_SHELL_BASENAMES.has(shebang.interpreter)
|
|
}
|
|
|
|
/** Drops a leading `#!` line; the generated runner carries its own interpreter line. */
|
|
export function stripLeadingShebangLine(script: string): string {
|
|
if (!isShebangLine(script.split('\n', 1)[0] ?? '')) {
|
|
return script
|
|
}
|
|
const lineEnd = script.indexOf('\n')
|
|
return lineEnd === -1 ? '' : script.slice(lineEnd + 1)
|
|
}
|
|
|
|
function findInterpreterIndex(tokens: string[]): number {
|
|
for (let index = 0; index < tokens.length; index++) {
|
|
const basename = executableBasename(tokens[index])
|
|
// Why: `env` (and its `-S` split-string form) only forwards to the real interpreter.
|
|
if (basename === '' || basename === 'env' || basename.startsWith('-')) {
|
|
continue
|
|
}
|
|
return index
|
|
}
|
|
return -1
|
|
}
|
|
|
|
function parseShellOptions(tokens: string[]): string[] {
|
|
const options: string[] = []
|
|
for (let index = 0; index < tokens.length; index++) {
|
|
const token = tokens[index]
|
|
if (SET_LONG_OPTION_FLAG_PATTERN.test(token)) {
|
|
const optionName = tokens[index + 1]
|
|
if (optionName && SHELL_OPTION_NAME_PATTERN.test(optionName)) {
|
|
options.push(token, optionName)
|
|
index++
|
|
}
|
|
continue
|
|
}
|
|
if (SET_OPTION_FLAG_PATTERN.test(token)) {
|
|
options.push(token)
|
|
}
|
|
}
|
|
return options
|
|
}
|
|
|
|
function executableBasename(token: string): string {
|
|
return (
|
|
token
|
|
.replaceAll('\\', '/')
|
|
.split('/')
|
|
.pop()
|
|
?.toLowerCase()
|
|
.replace(/\.exe$/, '') ?? ''
|
|
)
|
|
}
|