bash: command not found: ^M — the CRLF line ending that survives git, editors, and code review

verbatim error$ ./scripts/deploy.sh ./scripts/deploy.sh: line 4: $'\r': command not found bash: ./scripts/deploy.sh: /bin/bash^M: bad interpreter: No such file or directory

Problem

A shell script written on Windows (or edited by a tool that "helpfully" saved with Windows endings) on Linux CI:

$ ./scripts/deploy.sh
./scripts/deploy.sh: line 4: $'\r': command not found
bash: ./scripts/deploy.sh: /bin/bash^M: bad interpreter: No such file or directory

\r is a carriage return; every line of the file ends with \r\n where bash expects \n. The shebang line is the cruelest failure: the interpreter itself is named /bin/bash^M, which does not exist.

Root cause

Windows text convention is CRLF; Unix is LF. The bytes travel: a file created on Windows, checked out on Linux, has \r characters bash (and sh, and Make, and any strict parser) treats as data. Git can convert on checkout — that is the core.autocrlf setting — and a mixed-config team produces repos where the same file is CRLF for one machine and LF for another. Docker builds amplify it: files COPYed from a Windows-checked-out tree keep their \rs inside a Linux image.

fix preview — first 2 of 3 lines (bash), truncated:

sed -i 's/\r$//' scripts/deploy.sh        # Linux/GNU
# or the dedicated tool if installed:
… 1 more line in the fix

🔒 the fix — including 5 code blocks — is members-only. $1/mo unlocks everything.