Problem: bash script reports $'\r': command not found / bad interpreter: /bin/bash^M - Windows CRLF mixed in —— Trove problem library

What you will run into

Running a script written on Windows inside WSL/Linux reports setup.sh: line 2: $'true\r': command not found, or bash: ./setup.sh: /bin/bash^M: bad interpreter.

The \r / ^M in the error is an invisible newline leftover - scripts saved with Notepad or Windows editors carry it.

Some scripts "partially run, then a few lines suddenly command not found" - exactly those commands whose line endings carry CR.

Why this happens

Windows text files end lines with CRLF (\r\n), Linux only uses LF (\n):

• CR after the command name: bash treats true\r as one whole command name -> $'true\r': command not found (CR inside echo arguments usually doesn't error, so it's "flaky");
• CR in the shebang line: #!/bin/bash\r makes the kernel look for the /bin/bash\r (^M) interpreter -> bad interpreter.

Common sources: Notepad saves, Windows editors defaulting to CRLF, misconfigured git checkout (core.autocrlf).

A trailing CR ( , 0x0D) is an ordinary character in Linux text processing, not a line separator: when bash parses a script line, the whole line (including the trailing ) becomes the command name, and true ≠ true, hence $'true ': command not found.

Shebangs are parsed by the kernel: it reads the first line to find the interpreter path, and #!/bin/bash makes it look for a file named /bin/bash (which does not exist) → bad interpreter.

The two failures happen at different layers: command-name errors at the shell layer (command not found), shebang errors at the kernel exec layer (bad interpreter).

Deterministic takeaway: an error containing $'... ' or ^M means CRLF contamination — sed -i 's/ $//' or dos2unix cleans it in one shot;

if it reappears after git checkout, it is the line-ending policy (core.autocrlf/.gitattributes — see git-crlf); fix the repo config instead of editing files one by one;

fixed diagnostic: file <script> shows CRLF, cat -A shows ^M$.

Step by step

1. Confirm it's CRLF — Required

file setup.sh

Output containing with CRLF -> that's it (or cat -A setup.sh to see whether line endings end with ^M$).

2. Strip the CR — Required

sed -i 's/\r$//' setup.sh

Or dos2unix setup.sh (install it first with sudo apt install dos2unix if missing).

3. Only the shebang line is broken — Required

bash setup.sh invoking the interpreter explicitly bypasses shebang parsing (but body CR remains); the root fix is still stripping CR.

4. Prevention — Required

• Edit scripts inside Linux (vi/nano);
• Choose LF/Unix line endings in Windows editors (VS Code: bottom-right switch);
• Unify the core.autocrlf policy in git repos;
• After copying a script, run file setup.sh first.

How to confirm it works

bash setup.sh

No more command not found / bad interpreter = success. Measured: after sed -i 's/\r$//', the script works, exit=0; before the fix, body CR reported $'true\r': command not found (exit=127) and shebang CR reported bad interpreter (exit=126).

Other environments

Symptom

Running a script written on Windows inside WSL/Linux reports two typical error classes:

$ bash setup.sh
setup.sh: line 2: $'true\r': command not found

$ ./setup.sh
bash: ./setup.sh: /bin/bash^M: bad interpreter: No such file or directory

• The \r (or ^M) in the error is an invisible newline leftover - scripts saved with Notepad/Windows editors carry it.
• Some scripts look like they "partially run", then a few lines suddenly command not found - exactly those commands whose line endings carry CR.

Cause

1. Windows text files end lines with CRLF (\r\n), Linux only uses LF (\n).
2. CR after the command name: bash treats true\r as one whole command name -> $'true\r': command not found (CR inside echo arguments usually doesn't error, so it's "flaky").
3. CR in the shebang line: #!/bin/bash\r makes the kernel look for the /bin/bash\r (^M) interpreter -> bad interpreter.
4. Common sources: Notepad saves, Windows editors defaulting to CRLF, misconfigured git checkout (core.autocrlf related, see the git-crlf entry).

Solution

1. Quick fix (convert line endings):

   sed -i 's/\r$//' setup.sh
   # or dos2unix setup.sh

1. If only the shebang line is broken: bash setup.sh invoking the interpreter explicitly bypasses shebang parsing (but body CR remains); the root fix is still stripping CR.
2. Prevention: edit scripts inside Linux (vi/nano); choose LF/Unix line endings in Windows editors; unify the core.autocrlf policy in git repos (complementary to the git-crlf entry); after copying a script run file setup.sh first (showing with CRLF means hit).