🚨 Linux Error: bad interpreter: No such file or directory — Cause, Fix, and Troubleshooting Guide

Summary

bad interpreter: No such file or directory means the kernel read your script’s shebang (#!) line and could not find the interpreter it points to. The classic and maddening case: the file looks fine, /bin/bash clearly exists, yet it still fails — because a Windows \r (carriage return) is hiding at the end of the shebang line, so the kernel is actually looking for an interpreter named /bin/bash\r. A wrong path, a missing package, or a BOM produces the same message.

Common Symptoms

• ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory
• -bash: ./script: /usr/bin/python: bad interpreter: No such file or directory
• A script edited on Windows or pasted through a web form suddenly stops running on Linux.
• bash ./script.sh works, but ./script.sh fails.
• The error appears after cloning a repo from a Windows contributor.

Most Likely Causes of the ‘bad interpreter: No such file or directory’ Error

Production causes, most common first:

1. CRLF line endings. The file was saved with Windows \r\n, so the shebang becomes #!/bin/bash\r. The trailing ^M is part of the path the kernel searches for. This is by far the most common cause.
2. Wrong interpreter path. The shebang says #!/usr/bin/python but the binary lives at /usr/bin/python3, or #!/bin/bash on a system where bash is at /usr/local/bin/bash.
3. Interpreter not installed. #!/usr/bin/python on a minimal container that ships no Python at all.
4. UTF-8 BOM before the shebang. An editor prepended ef bb bf, so the first bytes are not #!.
5. Leading whitespace or a blank first line. The #! must be the very first two bytes of the file.
6. Distro path differences. env at /bin/env vs /usr/bin/env; hardcoding the wrong one breaks portability.

Quick Triage

# Reveal hidden carriage returns — look for ^M or \r
cat -A ./script.sh | head -1

# Show the raw first line bytes
head -1 ./script.sh | hexdump -C

# Does the interpreter the shebang names actually exist?
head -1 ./script.sh

A \r shown as ^M at the end of the first line is your smoking gun.

Diagnostic Commands

file ./script.sh

Reports ASCII text, with CRLF line terminators when Windows line endings are present — an instant diagnosis.

head -1 ./script.sh | hexdump -C

Shows the exact bytes of the shebang. Look for a trailing 0d (\r) before the 0a (\n), or a leading ef bb bf BOM before 23 21 (#!).

cat -A ./script.sh | head

cat -A renders \r as ^M and line ends as $. A shebang ending in ^M$ confirms CRLF.

sed -n '1p' ./script.sh | od -c | head

Another way to see the literal characters, including \r and \0.

ls -l /bin/bash /usr/bin/env /usr/bin/python3

Confirm the interpreter path in the shebang actually exists. which bash / command -v python3 tell you where it really lives.

type -a bash python3

Lists every location an interpreter is found, so you can correct the shebang path.

Fix / Remediation

1. Strip CRLF line endings (most common fix). Any of these work:

   dos2unix ./script.sh                 # if installed
   sed -i 's/\r$//' ./script.sh         # portable, no extra package

   On RHEL/Rocky install with dnf install dos2unix; on Ubuntu/Debian apt install dos2unix.

2. Remove a UTF-8 BOM.

   sed -i '1s/^\xEF\xBB\xBF//' ./script.sh

3. Fix the interpreter path. Point the shebang at the real location, or prefer env for portability:

   #!/usr/bin/env bash
   #!/usr/bin/env python3

   env searches PATH, sidestepping distro path differences (e.g. /bin vs /usr/bin).

4. Install the missing interpreter.

   apt install python3      # Ubuntu/Debian
   dnf install python3      # RHEL/Rocky

5. Ensure #! is the first two bytes. Delete any blank first line or leading spaces before the shebang.

   Warning: Before a bulk sed -i or find ... -exec dos2unix across a repo, commit or back up first — a bad glob can rewrite binary files and corrupt them. Scope the find to text extensions (-name '*.sh').

Validation

file ./script.sh                 # should say: ASCII text (no CRLF)
head -1 ./script.sh | hexdump -C # shebang ends in 0a, not 0d 0a
./script.sh                      # runs cleanly

Prevention

• Configure your editor to save shell scripts with LF endings (VS Code: "files.eol": "\n").
• Add a .gitattributes rule: *.sh text eol=lf so Git normalizes line endings on checkout.
• Prefer #!/usr/bin/env bash over hardcoded paths for cross-distro portability.
• Add a CI lint step (e.g. shellcheck plus a CRLF grep: ! grep -rlP '\r$' scripts/) to catch bad endings before merge.
• On minimal container images, verify the interpreter is actually present in the final layer.

Related Errors

• Linux Error: No such file or directory (when the file exists)
• Linux Error: Exec format error
• Linux Error: command not found
• Linux Error: Permission denied

Final Notes

When /bin/bash obviously exists but you still get bad interpreter: No such file or directory, stop staring at the path and check the bytes — a hidden \r from a Windows editor is the culprit nine times out of ten. file and cat -A expose it instantly, and sed -i 's/\r$//' fixes it. Standardize on LF endings and env shebangs to keep it from coming back.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.