setup.ps1 failed to parse with errors that pointed nowhere useful:
Missing closing '}' in statement block
Unexpected token ')'The braces and parens were all balanced. The actual culprit was a single punctuation character in a warning message: an em-dash.
// 01 — THE SETUP
A warning string in the script contained a nicely-typeset em-dash: — (U+2014), saved in the file as UTF-8 (bytes E2 80 94).
// 02 — THE CULPRIT
PowerShell 5.1 reads .ps1 files as Windows-1252 by default, not UTF-8. In Windows-1252, the byte 0x94 is a right double-quotation mark ("). So the parser, walking the UTF-8 em-dash byte by byte, hit 0x94 and saw a closing quote, which prematurely ended the string literal. Everything after it became unbalanced: an open quote with no close, then braces and parens that no longer matched. The reported errors were downstream rubble; the real fault was one mis-decoded byte.
// 03 — THE FIX
Replace the typographic character with plain ASCII:
— → --A double hyphen reads the same to a human and is identical across encodings. The script parsed instantly.
TAKEAWAYS
- PowerShell 5.1 defaults to Windows-1252, not UTF-8. Any non-ASCII character in a
.ps1— em-dashes, smart quotes, accented letters — can be mis-decoded into something that breaks the parse. - Syntax errors that point at balanced braces are often encoding errors in disguise. Look for the non-ASCII character upstream of the reported line.
- Keep scripts ASCII-only unless you’ve explicitly set the encoding. Typography belongs in prose, not source.
NEXT
- Concept — streaming vs batch: why sub-second aggregation matters.
