Skip env flags (-S, --split-string) in Windows shebang parser

Closed
RO
4mo ago
+210-2

Fixes #28594

Problem

When a package like @google/gemini-cli uses the shebang #!/usr/bin/env -S node --no-warnings=DEP0040, Bun's Windows shebang parser treats -S as the interpreter program name instead of recognizing it as a flag to env. This causes the Windows shim to fail with:

error: interpreter executable "-S" not found in %PATH%

Root Cause

In BinLinkingShim.zig, Shebang.parse() tokenizes the shebang line and after identifying /usr/bin/env, takes the very next token as the program name. For #!/usr/bin/env -S node --no-warnings=DEP0040, that next token is -S — an env flag, not the interpreter.

The resulting launcher command line becomes -S node --no-warnings=DEP0040, causing the shim to try to spawn -S as an executable.

Fix

After identifying /usr/bin/env or /bin/env, skip any tokens that start with - (env flags like -S, --split-string, -i, -v, etc.) to find the actual interpreter program. Handle -- as the standard end-of-options separator.

This correctly resolves the launcher to node --no-warnings=DEP0040 with is_node_or_bun=true.

Verification

  • Test covers -S, --split-string, and -- separator variants
  • Tests are Windows-only (test.skipIf(!isWindows)) since the Windows shim code path is only exercised on Windows (Linux/macOS use kernel shebang handling via symlinks)