Files
orca/config/scripts
Merge Sim 82de6adbbf fix(repo): pin the Windows CLI shim to CRLF, the bytes it already ships
The parent commit pins the whole tree to LF and leaves one question open:
whether resources/win32/bin/orca.cmd should be an exception. Measured against
the shipped v1.4.192 installer, it should -- though for a narrower reason than
the open question assumed. See the finding below.

The release Windows runner pins nothing and sets no core.autocrlf, so it
converts this file on checkout. The committed blob is 644 bytes with 0 CR; the
copy inside orca-windows-setup.exe is 665 bytes with 21 CR, and is sha256-
identical to that blob with every LF doubled. 665 - 644 = 21, the file's line
count. The same installer carries its own control: the seven files under
resources/plugins/ were already pinned eol=lf and shipped unconverted, byte-
identical to their blobs. One artifact proves both that the conversion is live
and that a pin overrides it.

That reverses the framing. Pinning CRLF reproduces today's artifact exactly;
it is leaving the file to the blanket rule that flips a shipped byte. Verified
across every checkout config: with the pin the working tree is 665 B / 21 CR
under core.autocrlf=true, false and input alike; without it, 644 B / 0 CR under
all three, and a real windows-2022 runner confirms `i/lf w/crlf` with the pin
and `i/lf w/lf` without. The index blob is unchanged either way.

FINDING: LF is not broken. check-windows-launcher-line-endings.ps1 ran the shim
both ways on windows-2022 and both encodings passed both arms -- the goto-label
hazard did not reproduce. So this pin is a consistency choice, not a
correctness fix: it reproduces the bytes v1.4.192 shipped and stops them being
decided by a build-image default nobody controls. A uniform-LF decision would
now be defensible; what should survive either way is that something finally
executes this file. Until now nothing did -- smoke-packaged-cli.mjs resolves
the packaged CLI to resources/bin/orca.exe on win32, never the .cmd beside it.

The shim sits outside the parent gate's population (no shebang, mode 100644),
so the two rules cannot contradict each other; a test asserts that.

check-line-ending-policy.mjs now asserts the exception rather than merely
permitting it: the blob must still be LF and eol must resolve to crlf. An
exception nothing checks is how this file's encoding became a runner-image
accident in the first place.

check-windows-launcher-line-endings.ps1 adds the empirical half on the existing
package (windows) job, first step after checkout, one second. It confirms the
runner really wrote CRLF, then runs the shim's guard path and its fall-through
under a real cmd.exe, using a copy of cmd.exe as the orca.exe the shim requires
-- without one the shim exits 1 before reaching either arm. It reports the LF
verdict without ever failing the job on it. Both checks were watched failing
with the pin removed before this landed.
2026-08-29 19:40:04 -07:00
..
2026-05-15 05:44:25 -04:00