Nicholas Qin1. 这就是那个让无数人抓狂的换行符问题
如果你在Linux或macOS终端里执行一个shell脚本，结果屏幕上蹦出来这么一行：
code复制/bin/bash^M: bad interpreter: No such file or directory
别慌，你遇到的不是脚本写错了，也不是系统坏了，而是Windows和Linux之间一个非常"隐蔽"的差异——换行符。
这个错误几乎每个跨平台开发的人都踩过。我刚入行那会儿，第一次在Windows上用记事本写了个部署脚本，高高兴兴传到服务器上一执行，直接就是这行红字。当时我盯着/bin/bash^M看了半天，心想：这个^M是什么鬼？/bin/bash明明存在啊，怎么会找不到解释器？
后来才明白，这其实是一个文本编码层面的经典问题。简单来说，Windows系统里的文本文件，每一行结尾用的是\r\n（回车+换行），而Linux和macOS用的是\n（只有换行）。当你在Linux下执行一个带着\r结尾的脚本时，系统会把\r当成命令解释器路径的一部分，于是想去找/bin/bash\r这个文件，当然找不到，就报No such file or directory。
这个错误危害不小，因为它是"看不见摸不着"的，你用cat查看脚本内容时，一切看起来完全正常，甚至用vim打开也不一定能马上发现问题。但它就是会让你所有部署、打包、构建流程卡死在这一步，特别折磨人。
这篇文章就专门来解决这个问题。我会从原理讲起，再给出最实用的几种修复方法，最后聊一聊如何从源头上避免它，让你彻底告别这个^M噩梦。不管你是刚接触Linux的新手，还是被这个错误折磨过几次的运维老手，这篇都能给你一些直接能用的东西。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先搞懂换行符的来龙去脉
2.1 为什么Windows和Linux的换行不一样
这事儿得从打字机时代说起。早期的电传打字机在换行时，需要两个动作：一个是把打印头移回行首，也就是回车（Carriage Return，简称CR），另一个是把纸往上滚一行，也就是换行（Line Feed，简称LF）。很多系统在实现时只用一个字符来表示换行，但用哪个字符并没有统一标准。
- Unix/Linux 选择了
LF，也就是ASCII码里的\n。 - Windows 选择了
CRLF，也就是\r\n。 - 老款Mac 用的是
CR，也就是\r，不过现在的macOS也是LF了。
所以你看，这纯粹是历史遗留问题。Windows为了兼容老系统，把\r\n作为默认换行，而Unix从一开始就只用\n。两个系统都没有错，只是标准不同而已。
2.2 ^M到底是什么
当你把一个Windows文件直接放到Linux下执行时，Linux看到的每一行结尾都多了一个\r字符。这个\r在终端里会被显示成^M——这不是两个字符，它只是\r的转义表示方式。
所以/bin/bash^M的实际含义是：命令行里输入的解释器路径是/bin/bash\r，而系统去/bin/bash\r这个路径下找解释器，结果是找不到，所以报错。
你可以这样验证一下：
bash复制ls -l /bin/bash
如果输出显示这个文件存在，但你执行脚本却报bad interpreter，那八成就是换行符的问题。也可以用cat -A命令直接查看隐藏字符：
bash复制cat -A your_script.sh
如果每行末尾都显示^M$，那$是正常的行尾，^M就是多余的回车符，问题坐实了。
2.3 还有哪些地方会被这个坑到
换行符问题不只是影响Shell脚本。实际上，只要是"文本文件跨系统使用"，都可能踩坑：
- Python脚本：
python3在Linux下执行Windows写的.py文件，有时也会报语法错误或者莫名其妙的解析问题。 - Dockerfile：在Windows上写的Dockerfile传到Linux上
docker build，有时候会出现诡异提示。 - 配置文件：
.env、.ini、.conf这些配置文件中混入\r，可能导致配置项解析失败，甚至服务启动报错。 - SQL脚本：执行迁移SQL时，Windows下写的脚本可能导致末尾多出字符，影响SQL解析。
- Git操作：Git默认会做换行符转换，但如果配置不当，会在仓库里混入两种换行符，造成
diff混乱。
所以说，^M绝对不是Shell脚本独有