Skip to content

fix(just): replace Unicode in Windows PowerShell recipe strings#260

Merged
githubrobbi merged 2 commits into
mainfrom
fix/win-ps-utf8-encoding
May 16, 2026
Merged

fix(just): replace Unicode in Windows PowerShell recipe strings#260
githubrobbi merged 2 commits into
mainfrom
fix/win-ps-utf8-encoding

Conversation

@githubrobbi
Copy link
Copy Markdown
Collaborator

Root cause

Windows PowerShell 5.1 (powershell.exe) reads UTF-8-no-BOM files as the system ANSI code page (CP1252). just writes #!powershell recipe bodies as UTF-8 without a BOM, so any multi-byte Unicode codepoint whose UTF-8 continuation byte lands in 0x91-0x94 decodes as a smart quotation mark (U+2018-U+201D), which the PowerShell tokenizer treats as a string delimiter. This silently terminates string literals mid-line and surfaces downstream as Unexpected token / Missing closing } errors far from the real cause.

Reported failure

> just bake-day
At C:\Users\rnio\AppData\Local\Temp\just-8Y4WhE\bake-day.ps1:259 char:1
+ } else {
+ ~
Unexpected token "}" in expression or statement.
error: Recipe `bake-day` failed with exit code 1

Line 259 of just/dev.just contains } else {. The actual breakage is upstream: the em-dash (UTF-8 E2 80 94) on line 227 decodes to â€" under CP1252; the trailing 0x94 byte is U+201D (right double quote) which terminates the surrounding "..." string early, leaving PowerShell to mis-parse everything until it gives up at the next }.

Affected recipes

  • just/dev.just::bake-day (the reported failure)
  • just/dev.just::update-tools (same trap, same file)
  • just/build.just::sync (em-dash on line 548)

Fix

Replaced all Unicode in [windows] #!powershell string literals with ASCII tags ([OK], [FAIL], [WARN], [TIP], [DONE], [Rust], [Pkg], etc.). Unicode in # comments was left intact — the tokenizer skips comment bodies. Unix recipe variants are unchanged.

Added a comment block above set windows-shell in just/shared.just documenting:

  • The CP1252/UTF-8 trap with the exact byte sequences
  • The ASCII-only rule for future Windows recipes
  • Why we can't just switch to PowerShell 7 (operator baseline)

Verification

  • just --evaluate parses clean on Mac
  • Byte-scanner confirms 0 dangerous bytes (0x91-0x94) in any PowerShell string across all just/*.just files
  • Full pre-push gate (22 jobs, including lint-ci-windows) passed locally

Test plan

  • just bake-day runs to completion on Windows (was the reported failure)
  • just update-tools parses on Windows
  • just sync parses on Windows

Windows PowerShell 5.1 (powershell.exe) reads UTF-8-no-BOM files as the
system ANSI code page (CP1252).  When just writes a #!powershell recipe
body to a temp file, multi-byte Unicode codepoints whose UTF-8
continuation byte lands in 0x91-0x94 decode as smart quotation marks
(U+2018-U+201D), which the PowerShell tokenizer treats as string
delimiters.  This silently terminates string literals mid-line and
surfaces downstream as "Unexpected token" / "Missing closing {" errors
far from the real cause.

The reported failure mode:

  > just bake-day
  At C:\Users\rnio\AppData\Local\Temp\just-8Y4WhE\bake-day.ps1:259 char:1
  + } else {
  + ~
  Unexpected token "}" in expression or statement.
  error: Recipe `bake-day` failed with exit code 1

Line 259 of dev.just contains `} else {`.  The actual breakage is
upstream — the em-dash `—` (UTF-8 E2 80 94) on line 227 decodes to
`â€"` under CP1252; the trailing 0x94 byte is U+201D (right double
quote) which terminates the surrounding "..." string early, leaving
PowerShell to mis-parse everything until it gives up at the next `}`.

Three recipes were affected:
- just/dev.just::bake-day    (the reported failure)
- just/dev.just::update-tools (same trap, same file)
- just/build.just::sync       (em-dash on line 548)

All Unicode in PowerShell string literals replaced with ASCII
equivalents.  Unicode inside `#` comments is left intact (the
tokenizer skips comment bodies).  Unix recipe variants of the same
recipes are unchanged.

An explanatory comment block has been added to just/shared.just
above the `set windows-shell` directive documenting the trap and
the ASCII-only rule for future contributors.
@githubrobbi githubrobbi enabled auto-merge (squash) May 16, 2026 13:27
@githubrobbi githubrobbi merged commit fbc6063 into main May 16, 2026
24 checks passed
@githubrobbi githubrobbi deleted the fix/win-ps-utf8-encoding branch May 16, 2026 13:42
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