bad interpreter: ^Mの直し方｜改行コードCRLF

/bin/bash^M: bad interpreter: no such file or directory は、シェルスクリプトの改行コードが Windows 形式（CRLF）になっているときのエラーです。 1行目の #!/bin/bash の行末に、目に見えない \r（^M）が付き、OS が「/bin/bash\r というプログラム」を探して見つからないために起きます。

同じ原因でも、実行のしかたによってエラー文が変わります。 ここに当てはまるものがあれば、改行コードを疑います。

直し方は、改行を LF に変えることです。

sed -i 's/\r$//' deploy.sh      # どの Linux にもある sed で直す
# または
dos2unix deploy.sh              # dos2unix が入っていれば

確認環境：Ubuntu 24.04（bash 5.2.21、zsh、dash）、Python 3、Docker 29.4、git 2.43、dos2unix 7.5.1（確認日 2026年10月11日）。CRLF のスクリプトを作り、それぞれの方法で実行して再現しました。

再現：CRLF のスクリプトを実行する

#!/bin/bash
echo "start"
...

Windows のメモ帳や、改行コードの設定が CRLF のエディタで作ると、各行の最後が \r\n になります。

$ ./deploy.sh                          （bash 5.2）
bash: ./deploy.sh: cannot execute: required file not found

$ ./deploy.sh                          （zsh）
zsh: ./deploy.sh: bad interpreter: /bin/bash^M: no such file or directory

ファイルはあるのに「見つからない」と言われるのが特徴です。見つからないのはスクリプトではなく、/bin/bash\r（末尾に \r が付いたシェル）です。

bash に直接渡すと、別のエラーになる

bash deploy.sh のように実行すると、1行目は使われずに中身が実行され、行ごとにおかしなエラーが出ます。

$ bash run.sh
run.sh: line 2: $'\r': command not found                       ← 空行が「\r というコマンド」に
start
run.sh: line 6: cd: $'/tmp/nosuch\r': No such file or directory  ← パスの末尾に \r

$ bash deploy.sh
start
deploy.sh: line 9: syntax error: unexpected end of file       ← if ... fi の fi\r が fi と認識されない

$'...\r' という表示が出たら、ほぼ確実に CRLFです。さらに、mkdir -p "$DIR" の行では、名前の末尾に \r が付いたフォルダーが作られていました（ls | cat -A で logs^M^M$ と表示）。途中まで動いて、おかしな名前のファイルやフォルダーを作ってしまうこともあります。

Docker では「no such file or directory」

FROM ...
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

$ docker run --rm crlf:1
exec /entrypoint.sh: no such file or directory

ファイルは COPY されているのに no such file or directory になります。Windows で編集した entrypoint.sh をビルドしたときに多いパターンです。LF に直してビルドし直すと、container start と表示されて動きました。

確かめ方：file と cat -A

$ file deploy.sh
deploy.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

$ cat -A deploy.sh | head -3
#!/bin/bash^M$
echo "start"^M$
DIR=logs^M$

$ grep -c $'\r' deploy.sh
8                                       ← \r を含む行の数

直し方

Mac の sed は -i の書き方が違う（sed -i '' 's/\r$//' ファイル名）ため、Mac では dos2unix（Homebrew）か VS Code が手軽です。

再発を防ぐ：.gitattributes

Windows と Linux・Mac の両方で開発していると、git が checkout のときに改行コードを CRLF に変えることがあります（core.autocrlf=true の設定）。確認環境でも、LF でコミットしたスクリプトを core.autocrlf=true で clone すると、CRLF になっていました。

$ git -c core.autocrlf=true clone ... gc1
$ file gc1/deploy.sh
gc1/deploy.sh: ... with CRLF line terminators          ← CRLF で取り出された

リポジトリに .gitattributes を置くと、設定に関係なく LF で取り出せます。

# .gitattributes
*.sh text eol=lf

$ git -c core.autocrlf=true clone ... gc2
$ file gc2/deploy.sh
gc2/deploy.sh: Bourne-Again shell script, ASCII text executable   ← LF のまま
$ ./deploy.sh
ok

git の公式ドキュメントにも、*.sh text eol=lf で .sh ファイルを LF で取り出す例が載っています。Dockerfile の ENTRYPOINT に使うファイルや、*.py など Linux で実行するスクリプトも同じように指定します。

すでに CRLF でコミットされているファイル

.gitattributes を足しただけでは、すでにリポジトリに入っている CRLF のファイルは直りません。

git add --renormalize .          # リポジトリの中身を LF にそろえる
git commit -m "改行コードを LF にそろえる"
rm deploy.sh && git checkout -- deploy.sh    # 手元のファイルも取り出し直す

$ git ls-files --eol deploy.sh
i/lf    w/crlf  attr/text eol=lf    deploy.sh     ← renormalize 直後：リポジトリは LF、手元はまだ CRLF
i/lf    w/lf    attr/text eol=lf    deploy.sh     ← 取り出し直したあと：両方 LF

git ls-files --eol で、リポジトリ（i/）と手元（w/）の改行コードを別々に確認できます。 既存のリポジトリの改行コードの設定（autocrlf と .gitattributes の関係）は、関連記事の「Git改行コード設定」で詳しく比べています。

確認の手順（チェックリスト）

よくある質問

Q. 実行権限（chmod +x）も付けています。 A. 権限が無いときのエラーは Permission denied です。権限があるのに「見つからない」と言われるなら、改行コードを疑います。

Q. エディタでは何も見えません。 A. \r は表示されない文字なので、多くのエディタでは見えません。file や cat -A、エディタの改行コードの表示（VS Code の右下など）で確かめます。

まとめ

• 1行目の #!/bin/bash の行末に \r が付き、/bin/bash\r を探して見つからないのが原因
• エラー文はシェルや実行のしかたで違う。bash 5.2 は required file not found、zsh は bad interpreter: /bin/bash^M、Docker は no such file or directory
• $'\r' と表示されたら CRLF
• 確かめるのは file（with CRLF line terminators）と cat -A（^M$）
• 直すのは sed -i 's/\r$//' か dos2unix
• 再発を防ぐのは .gitattributes の *.sh text eol=lf。既存のファイルは git add --renormalize .

参考・出典

確認日はいずれも 2026年10月11日です。

• Git ドキュメント「gitattributes」（eol・End-of-line conversion）：https://git-scm.com/docs/gitattributes

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。