SubprocessModule: bridge import Subprocess to Shell.processLauncher

[odrobnik]

Closes the SwiftScript half of the polyglot subprocess unification. ShellKit shipped Shell.processLauncher (Cocoanetics/ShellKit#1) and SwiftBash registered BashProcessLauncher (Cocoanetics/SwiftBash#19); this PR lets a SwiftScript script write idiomatic swift-subprocess code and have it route through whatever launcher the bound shell carries.

import Subprocess

let r = try await Subprocess.run(
    Executable.name("git"),
    arguments: ["status"],
    output: Output.string(limit: 4096))

if r.terminationStatus.isSuccess {
    print(r.standardOutput ?? "")
}

Routing

• Standalone (no embedder) → DefaultProcessLauncher → swift-subprocess run(...) → real posix_spawn (macOS / Linux / Windows / Android).
• Under SwiftBash → BashProcessLauncher → resolves against the bash command registry. No posix_spawn, ever — pure-Swift builtins and registered SwiftPorts CLIs.
• Sandbox-bound without a virtualised launcher → ProcessLaunchDenied, surfaced to the script as a thrown error.

What v1 ships

Surface	Bridge
Executable.name(_:) / .path(_:)	static methods
Output.string(limit:) / Output.discarded	static method + static let
ErrorOutput.string(limit:) / ErrorOutput.discarded	symmetric
Subprocess.run(_:arguments:output:) and (_:arguments:output:error:)	dispatched by argument count behind a single empty-paren bridge key (matches the existing convention for static methods like Double.minimum)
ExecutionRecord.{terminationStatus, standardOutput, standardError, processIdentifier}	computed properties
TerminationStatus.{isSuccess, exitedCode, signaledCode}	case-extracting accessors stand in for pattern-matching the underlying enum

Output and ErrorOutput are separate type names because Swift's Error protocol identifier would collide with the swift-subprocess Error generic parameter when used script-side.

What v1 defers

environment: / workingDirectory: / input: parameters on run, closure-form run(...) { execution, stdout in ... } overloads, streaming AsyncSequence<Data> outputs, PlatformOptions. For v1 the environment + cwd come from ShellKit.Shell.current and stdin is empty — covers the 95%-case shell-out pattern.

Tests

SubprocessBridgeTests covers dispatch routing through a recording launcher:

• runRoutesThroughBoundProcessLauncher — argv passes through correctly
• executablePathPassesThroughVerbatim — Executable.path(...) preserved
• outputStringCapturesStdoutToStandardOutput — .string(limit:) captures bytes
• outputDiscardedReturnsNil — .discarded honors the contract even when launcher provides bytes
• errorStringCapturesStderr — stderr capture
• terminationStatusIsSuccessForExitZero / ExitedCodeForNonZero / SignaledCodeForSignaled
• sandboxedDenyLauncherSurfacesAsThrownError — ProcessLaunchDenied propagates to the script

Plus one platform-gated end-to-end test (#if os(macOS) || os(Linux)):

• standalonePathDelegatesToRealExec — Subprocess.run(.path(\"/bin/echo\"), arguments: [\"hi\"], output: .string(limit: 4096)) round-trips through DefaultProcessLauncher → real swift-subprocess and captures \"hi\\n\".

Suite: 10/10 pass. Full SwiftScript suite: 446/446 still green.

Notes

• Package.resolved bumps ShellKit pin to commit 4395986 (the one that landed Shell.processLauncher).
• SwiftScript itself does NOT add swift-subprocess as a direct dep — ShellKit owns that relationship; this module uses ShellKit's mirroring types (Executable, Arguments, Environment, ExecutionRecord, TerminationStatus).
• The bridge keys use empty () parens (\"static func Subprocess.run()\") — matches the existing convention for static methods (Double.minimum, Bool.random). Caller-supplied labels are stripped before the body sees the args; positional order is the contract.

Test plan

• CI green on macOS / iOS / tvOS / watchOS / Linux / Windows / Android
• Local: 10/10 new bridge tests + 446/446 full suite
• Follow-up: end-to-end test with SwiftScript-under-SwiftBash hitting a virtualised builtin (waits on Cocoanetics/SwiftBash#19 merging)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: af2f06cc21

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".