0425a3c0a1Shell scripts are stored as LF in git, but without an eol rule a Windows clone with core.autocrlf=true checks them out as CRLF. The trailing \r then breaks them when run in WSL/Linux -- e.g. `set -e` becomes `set -e\r` and dash/sh aborts with "set: Illegal option -". This bites developers who clone on Windows and run the repo's *.sh directly in WSL, increasingly common with the AMD Strix Halo ROCm-on-WSL support. Add `*.sh text eol=lf` so every shell script always checks out with LF regardless of the contributor's platform or core.autocrlf setting. All tracked *.sh use Unix shebangs; none need CRLF. PowerShell/batch scripts are left untouched -- they tolerate LF and are unaffected by this bug. Verified with `git ls-files --eol`: every *.sh now resolves to i/lf w/lf attr/text eol=lf. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
7 lines
309 B
Text
7 lines
309 B
Text
# Normalize Python files to LF line endings
|
|
*.py text eol=lf
|
|
|
|
# Always check out shell scripts with LF endings. Without this rule a Windows
|
|
# clone (core.autocrlf=true) rewrites them to CRLF, and the trailing \r breaks
|
|
# them when run in WSL/Linux (e.g. `set -e` -> "set: Illegal option -").
|
|
*.sh text eol=lf
|