Found while adding a Windows PowerShell 5.1 CI leg for #59, and carved out rather than folded into that PR — it predates it and has nothing to do with clustering tolerance.
What was measured
Run-Audit.ps1, Run-Infersharp.ps1 and Run-Roslyn.ps1 are UTF-8 without a BOM and contain non-ASCII characters. Windows PowerShell 5.1 reads a BOM-less .ps1 in the system ANSI codepage, so those bytes arrive as mojibake and the parser fails — the script does not run at all, and the error names a token rather than an encoding:
+ ... "and cluster better at {2} (AGENTS.md) — honouring your va ...
Unexpected token 'honouring' in expression or statement.
| file |
non-ASCII |
which |
Run-Audit.ps1 |
23 |
20 × —, §, ·, … |
Run-Infersharp.ps1 |
5 |
4 × —, § |
Run-Roslyn.ps1 |
2 |
2 × — |
Some sit in comments; several are in user-facing strings (throw "audit/ not found in $Worktree — is '$Ref' …", the dirty-tree message, the CodeQL DB notices).
Why it is worth an issue rather than a shrug
The scripts' own examples say pwsh ./Run-Audit.ps1, so pwsh-only is arguably the intent. But it is nowhere stated, and the failure mode is bad for a stand operator: not "unsupported shell", but a wall of parser errors pointing at innocent words. Anyone who types powershell ./Run-Audit.ps1 — the default shell in an older Windows console, and the one .ps1 still associates with on a stand — gets that.
So the choice is worth making explicitly, in one of two directions:
(a) Make them ASCII. ~30 substitutions, mostly — → --. The scripts then load under 5.1 and the property is enforceable — scripts/tests/Test-LineTolPolicy.ps1 already holds scripts/*.ps1 to ASCII by reading their bytes, and the same check extends to the runners in one line. Whether they then work under 5.1 is a separate question (Set-Content -Encoding utf8 means UTF-8-with-BOM there, and other 5.1 differences may bite), so this alone is not a support claim.
(b) Declare them pwsh-only and fail cleanly. Add #Requires -Version 7 at the top of each. 5.1 then refuses with an accurate message instead of a parser cascade. Cheapest, and honest — but note #Requires is evaluated after parsing, so it does not help while the file is still mis-decoded; (b) needs (a)'s ASCII fix, or a BOM, to actually produce the clean message.
Recommendation: (a) then (b). ASCII first so the file can be read at all, then #Requires -Version 7 so the refusal is a sentence rather than a stack of "Unexpected token".
Not in scope of #59
That PR only holds scripts/LineTolPolicy.ps1 and its test to ASCII, because the policy is dot-sourced by the runner and so must load wherever the runner does. Its 5.1 CI leg skips the Run-Audit.ps1 structural checks loudly, naming this issue's property as the reason, rather than asserting a compatibility the repo has never had.
Refs #59.
Found while adding a Windows PowerShell 5.1 CI leg for #59, and carved out rather than folded into that PR — it predates it and has nothing to do with clustering tolerance.
What was measured
Run-Audit.ps1,Run-Infersharp.ps1andRun-Roslyn.ps1are UTF-8 without a BOM and contain non-ASCII characters. Windows PowerShell 5.1 reads a BOM-less.ps1in the system ANSI codepage, so those bytes arrive as mojibake and the parser fails — the script does not run at all, and the error names a token rather than an encoding:Run-Audit.ps1—,§,·,…Run-Infersharp.ps1—,§Run-Roslyn.ps1—Some sit in comments; several are in user-facing strings (
throw "audit/ not found in $Worktree — is '$Ref' …", the dirty-tree message, the CodeQL DB notices).Why it is worth an issue rather than a shrug
The scripts' own examples say
pwsh ./Run-Audit.ps1, so pwsh-only is arguably the intent. But it is nowhere stated, and the failure mode is bad for a stand operator: not "unsupported shell", but a wall of parser errors pointing at innocent words. Anyone who typespowershell ./Run-Audit.ps1— the default shell in an older Windows console, and the one.ps1still associates with on a stand — gets that.So the choice is worth making explicitly, in one of two directions:
(a) Make them ASCII. ~30 substitutions, mostly
—→--. The scripts then load under 5.1 and the property is enforceable —scripts/tests/Test-LineTolPolicy.ps1already holdsscripts/*.ps1to ASCII by reading their bytes, and the same check extends to the runners in one line. Whether they then work under 5.1 is a separate question (Set-Content -Encoding utf8means UTF-8-with-BOM there, and other 5.1 differences may bite), so this alone is not a support claim.(b) Declare them pwsh-only and fail cleanly. Add
#Requires -Version 7at the top of each. 5.1 then refuses with an accurate message instead of a parser cascade. Cheapest, and honest — but note#Requiresis evaluated after parsing, so it does not help while the file is still mis-decoded; (b) needs (a)'s ASCII fix, or a BOM, to actually produce the clean message.Recommendation: (a) then (b). ASCII first so the file can be read at all, then
#Requires -Version 7so the refusal is a sentence rather than a stack of "Unexpected token".Not in scope of #59
That PR only holds
scripts/LineTolPolicy.ps1and its test to ASCII, because the policy is dot-sourced by the runner and so must load wherever the runner does. Its 5.1 CI leg skips theRun-Audit.ps1structural checks loudly, naming this issue's property as the reason, rather than asserting a compatibility the repo has never had.Refs #59.