The winget jq build on Windows emits CRLF; a trailing \r silently corrupts
`for x in $(jq ...)` loops and read-from-@tsv fields (single-value $() hides it).
Fix: override `jq(){ command jq "$@" | tr -d '\r'; }`. Windows-build-specific,
so it passes review on Mac/Linux. First hit + fix: the self-check skill engine.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.6 KiB
name, description, type
| name | description | type |
|---|---|---|
| jq on Windows emits CRLF — strip \r in shell loops | The winget jq build on Windows outputs CRLF line endings; a trailing \r silently corrupts `for x in $(jq ...)` loops and `read`-from-@tsv fields in harness bash scripts | feedback |
The jq binary installed via winget on Windows (C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links\jq.exe) emits CRLF line endings on multi-line output. A trailing \r then rides along on every value and silently breaks shell scripts.
Why: In for x in $(jq -r '.arr[]'), command substitution strips only the final trailing newline, so every interior word keeps its \r — "1password\r" instead of "1password". Paths/dir-tests/case membership then fail for items that actually exist (false "missing"). Single-value x="$(jq -r '.field')" is unaffected because $() strips the whole trailing CRLF, which is why the bug hides until you hit a loop. Git Bash, macOS, and Linux jq do NOT do this — it's Windows-build-specific, so it passes review on a Mac/Linux box and breaks on Windows.
How to apply: In any bash script that iterates jq output, neutralize it once at the top:
jq() { command jq "$@" | tr -d '\r'; } # override; \r is insignificant JSON whitespace, safe to strip everywhere
Or pipe individual loop-feeding calls through tr -d '\r'. Stripping \r from jq output is always safe (it's JSON whitespace and never wanted in raw string values). First hit + fix: the self-check skill engine (.claude/skills/self-check/scripts/self-check.sh), 2026-06-02. Related: feedback_python_windows.