Skip to content

fix(upgrade): make capa upgrade work on Windows - #304

Merged
Minitour merged 1 commit into
developfrom
fix/windows-upgrade
Oct 12, 2026
Merged

Minitour merged 1 commit into
developfrom
fix/windows-upgrade

Conversation

@Minitour

Copy link
Copy Markdown
Member

Summary

capa upgrade has never worked on Windows. It runs install.ps1 with powershell.exe (always Windows PowerShell 5.1), which reads a BOM-less script as Windows-1252. The UTF-8 ✓ / box-drawing glyphs decode to bytes that include 0x93, a smart quote PowerShell treats as a string delimiter, so the script fails to parse before running a single line. Nobody saw the error because the installer was spawned detached with stdout/stderr ignored.

What changed

  • install.ps1 is ASCII-only: plain OK and +---+ borders instead of glyphs, and [char]27 instead of `e (a 7.0-only escape that printed a literal e on 5.1)
  • capa upgrade runs the Windows installer in the foreground with inherited stdio and checks its exit code, same as the install.sh path. The installer already renames the running capa.exe aside (Upgrade fails on Windows #19), so capa doesn't need to exit first.
  • New test: install.ps1 must stay ASCII-only

Screenshots / logs

Before (PS 5.1 parsing the v2.3.0 install.ps1): parse errors: 6, starting with 213: Unexpected token 'Directory' in expression or statement.

After: parse errors: 0, and the installer runs to CAPA installed successfully!, exit 0.

Test plan

  • PS 5.1 Parser::ParseFile on the fixed script: 0 errors (6 before)
  • Ran the fixed installer via powershell.exe -File exactly as capa upgrade does: 2.2.0 to 2.3.0, exit 0
  • Reinstalled while capa.exe __server__ was running from the install dir: new binary landed, the old one was left as capa.exe.old
  • New ASCII test fails on develop's install.ps1 and passes here; upgrade-plan.test.ts 8/8

Checklist

  • Tests added or updated
  • bunx tsc --noEmit passes
  • bun run smells clean vs base (or CI Qlty Smells job green)
  • Docs updated (if user-facing) (none reference the old background behavior)

Takes effect from the release after this lands: the running capa runs whatever install.ps1 ships in the target release, so going from 2.3.0 to the next version is the first upgrade that benefits.

🤖 Generated with Claude Code

capa upgrade runs install.ps1 with powershell.exe, which is always
Windows PowerShell 5.1. 5.1 reads a BOM-less script as Windows-1252, so
the UTF-8 check mark and box-drawing glyphs decoded into stray smart
quotes and the script failed to parse. It never ran a single line.
The failure was invisible because the installer was spawned detached
with stdout/stderr ignored.

- install.ps1 is ASCII-only now; `e (a 7.0-only escape) becomes [char]27
- run the Windows installer in the foreground with inherited stdio and
  a real exit code, same as install.sh; the installer already renames
  the running capa.exe aside, so capa doesn't need to exit first
- test that install.ps1 stays ASCII-only
@Minitour
Minitour merged commit fcb2517 into develop Oct 12, 2026
8 checks passed
@Minitour
Minitour deleted the fix/windows-upgrade branch October 12, 2026 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant