Linux脚本报错/bin/bash^M怎么办？一文搞懂换行符原理与修复

1. 这就是那个让无数人抓狂的换行符问题

如果你在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的新手，还是被这个错误折磨过几次的运维老手，这篇都能给你一些直接能用的东西。

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脚本独有的问题，它是一个跨平台协作中非常普遍的现象。理解这个原理之后，很多类似的"灵异事件"都能想明白了。

3. 五招搞定/bin/bash^M错误

下面进入到实战环节。我把网上能搜到的方法整理了一下，加上我自己的使用经验，按照"简单高效"到"治本"的顺序，一个一个讲清楚。你可以根据自己手头的环境选择最合适的一种。

3.1 最快速的方式：用sed命令在线清理

如果你手头暂时不想装额外的软件，只想快速把脚本里的\r去掉，用sed是最直接的。

bash复制sed -i 's/\r$//' your_script.sh

这行命令的作用是：把每一行结尾的\r字符删掉，然后用-i参数直接写回原文件。

我建议在跑这个命令之前，先复制一份备份，防止误操作：

bash复制cp your_script.sh your_script.sh.bak
sed -i 's/\r$//' your_script.sh

然后再次执行脚本，问题基本就解决了。

3.2 用dos2unix工具一键转换

dos2unix是专门解决这类跨平台文本格式问题的命令行工具，用法极其简单：

bash复制dos2unix your_script.sh

如果你的系统里没有这个命令，可以用下面的方式安装：

bash复制# Debian/Ubuntu
sudo apt-get install dos2unix

# CentOS/RHEL
sudo yum install dos2unix

# macOS
brew install dos2unix

这个工具的好处是什么呢？它不只是去掉\r，还会处理文件的其他一些属性，比如文件编码、BOM头等，比较"懂行"。如果你的服务器上允许安装软件，我建议用这个一劳永逸。

3.3 用vim编辑器处理

如果你是个Vim用户，也有非常优雅的解法。用vim打开脚本文件：

bash复制vim your_script.sh

然后在底行模式执行：

code复制:set ff=unix

这个命令会把文件的换行符格式从dos改回unix，也就是把\r\n统一替换成\n。最后保存退出：

code复制:wq

这种方法的好处是不用记住各种命令行参数，所见即所得。而且vim还会明确提示你"fileformat=dos"，方便你确认问题所在。

3.4 用tr命令直接删除\r

tr是一个强大的字符处理工具，也可以用来删除所有\r字符：

bash复制tr -d '\r' < your_script.sh > new_script.sh
mv new_script.sh your_script.sh

这里-d表示删除指定字符，'\r'就是回车符。通过重定向生成新文件，再覆盖原文件。

这段命令和sed相比，思路稍有不同：tr是全局删除所有\r，不管它在行尾还是行中；而sed的's/\r$//'只删除行尾的\r。在绝大多数场景下，两者的效果是一样的，但如果你文件里有特殊情况，比如某个字符串中间确实需要保留\r，建议用s/\r$//，更精准。

3.5 用编辑器手动转换

很多图形化编辑器也支持一键切换行尾格式。

• VS Code：打开文件后，看右下角状态栏，会显示CRLF或LF，点击它，在弹出的菜单中选择LF，保存即可。
• Notepad++：菜单栏找到"编辑" -> "行尾字符" -> "Unix (LF)"，然后保存。
• Sublime Text：菜单栏"View" -> "Line Endings" -> "Unix"，然后保存。

这种方式适合那些经常在Windows和Linux之间来回编辑文件的人。因为图形化界面比较友好，不易误操作。

4. 定位问题根源：从哪里来的^M

知道了怎么改，很多人还会有一个疑问：我的脚本明明用VS Code写的，怎么还是出现了^M？

这里我来系统梳理一下^M可能的来源，帮你从源头上排查。

4.1 在Windows上直接创建或编辑脚本

最常见的来源就是在Windows上用记事本、老版本的写字板、或者某些默认以CRLF保存的编辑器写脚本。然后通过FTP、网盘、U盘等方式传到Linux服务器上。

尤其是用记事本，简直是重灾区。记事本保存的纯文本文件，换行符默认就是\r\n，除非你后续用VS Code之类的工具另存为LF，否则传到Linux上必踩坑。

4.2 Git的core.autocrlf配置问题

如果你把项目放在Git仓库里，在Windows上clone出来，又在Linux上直接执行，那么换行符很可能被Git"自动"转换了一次，也可能没转换，总之就是搞乱了。

Git里有一个配置项叫core.autocrlf，它的行为如下：

如果你在Windows上clone仓库时，Git自动把仓库里的LF转换成了本地的CRLF，你编辑完提交后，仓库里实际存的可能是CRLF，又被推到远端。这时候到Linux上再clone下来，就带着^M了。

解决办法是在Git仓库里统一换行符策略。推荐在项目根目录添加一个.gitattributes文件，强制指定shell脚本的换行符：

code复制*.sh text eol=lf
* text=auto

然后把仓库里的文件重新规范化：

bash复制git add --renormalize .
git commit -m "Normalize line endings"

这样做之后，无论你是在哪个操作系统上clone、编辑，只要遵循Git的规范，脚本最终在版控里都是以LF存储的，Linux上直接执行就不会出问题。

4.3 FTP或网盘传输导致格式混杂

还有一种情况：你用Windows编辑后，通过FTP上传到Linux服务器，传输模式是ASCII（文本模式）。有些FTP客户端会在上传时自动转换换行符，有些不会。这取决于你用的是哪种FTP软件、默认模式是什么。

如果你用的是二进制模式上传，那文件内容原封不动，CRLF就会原样保留，执行时就出问题。

这里我给个实用建议：对于脚本类文件，统一在Linux侧用dos2unix或者sed修复，别太依赖FTP客户端的自动转换，因为不同客户端行为不一致，很容易出现"这台机器上传可以，那台机器上传就报错"的问题。

4.4 复制粘贴引入的隐藏字符

有时候你从一个网页、文档、聊天工具里复制一段代码，粘到终端里，肉眼看着没问题，但里面可能混入了不可见的字符。最常见的就是\r或者一些特殊空格。

这种问题比较隐蔽，因为你在终端里直接看是看不出来的。碰到了也别着急，用cat -A看一下行尾，再做处理就好。

5. 实操复盘：我从"报错"到"正常运行"的完整过程

说了这么多理论，我拿一个真实场景来完整演示一遍：从Windows上写一个部署脚本，传到Linux上执行报错，到一步步排查、修复、正常运行。

5.1 我的脚本原本长这样

这个脚本其实很简单，就是做一次Web项目的部署，内容如下：

bash复制#!/bin/bash
echo "开始部署..."
cd /opt/myapp
git pull origin main
npm install
npm run build
systemctl restart myapp
echo "部署完成"

在Windows上用VS Code写好，保存后通过FileZilla上传到CentOS服务器，然后chmod +x赋予执行权限。

5.2 执行报错，逐步排查

执行：

bash复制./deploy.sh

结果：

code复制-bash: ./deploy.sh: /bin/bash^M: bad interpreter: No such file or directory

我的第一反应是"文件权限没给对"，但ls -l deploy.sh看权限是-rwxr-xr-x，没问题。接着怀疑是不是#!/bin/bash写错了，但head -1 deploy.sh显示的就是#!/bin/bash。

后来想起来可以用cat -A看看隐藏字符：

bash复制cat -A deploy.sh

输出：

code复制#!/bin/bash^M$
echo "开始部署..."^M$
cd /opt/myapp^M$
...

这一下就全明白了——^M已经在每一行末尾等着我了。

5.3 修复并验证

用sed修复：

bash复制sed -i 's/\r$//' deploy.sh

再次cat -A deploy.sh，确认每行末尾只有$，没有^M。

重新执行：

bash复制./deploy.sh

输出正常：

code复制开始部署...
...
部署完成

整个流程走下来，其实也就两三分钟的事。但如果没有搞清楚原理，光靠瞎试，可能折腾很久都不知道问题出在哪。

5.4 我目前长期在用的"防坑流程"

经过几次被坑之后，我现在形成了一套自己的工作习惯，供你参考：

• 在Windows上写脚本时，VS Code右下角默认就让它保持在LF模式。设置方法：设置里搜"files.eol"，改成\n。
• Git仓库里统一加.gitattributes，锁定shell脚本和Dockerfile使用LF。
• 上传到Linux后，执行之前先养成习惯运行一次dos2unix或者sed -i清理。
• 部署脚本里也可以加一行自动清理的逻辑（比如先检查再执行），不过我更推荐在CI/CD流程里统一处理，别在业务服务器上留太多变数。

6. 常见问题与排查技巧速查

这里我把平时遇到的高频问题整理成一个表格，方便你在以后遇到相似情况时快速对应。

省流版：遇到^M报错，首选sed -i 's/\r$//' 文件名，其次安装dos2unix来用，配好Git的换行符策略才能标本兼治。

7. 从源头规避：多平台协作的换行符治理方案

前面那些方法都是在"出事之后再补救"，真正高手的做法是从源头就杜绝^M出现。这其实是跨平台开发中一个非常基础的工程规范问题。

7.1 约定统一的行尾风格

一个团队在做跨平台项目时，一定要约好：代码仓库里存储的文件统一用LF。

具体到工程上，就是把.gitattributes用好。下面是一个我常用的配置模板：

code复制# 所有文本文件默认按文本处理，自动探测换行符
* text=auto

# 对特定类型强制使用 LF
*.sh text eol=lf
*.py text eol=lf
*.js text eol=lf
*.ts text eol=lf
*.json text eol=lf
*.yml text eol=lf
*.yaml text eol=lf
Dockerfile text eol=lf
Makefile text eol=lf

# 二进制文件标记
*.png binary
*.jpg binary
*.gz binary

这样配置后，Git在checkout时会对这些文件做转换，但提交到仓库里的永远是LF。你在Windows上看工作区文件可能仍然是CRLF（取决于你的全局配置），但仓库内是干净的。

7.2 编辑器层面统一设置

• VS Code：设置中搜索files.eol，设为\n。这样所有新建文件默认都用LF。
• Sublime Text：设置"default_line_ending": "unix"。
• Notepad++：设置"首选项" -> "新建文档" -> "Unix (LF)"。

另外，如果团队里有使用不同编辑器的同事，可以在项目根目录放一个.editorconfig文件，让主流IDE自动遵循：

code复制root = true

[*]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 4
insert_final_newline = true
trim_trailing_whitespace = true

.editorconfig的兼容性很好，VS Code、IntelliJ系列、Sublime等都支持，装个插件就能自动生效。

7.3 CI/CD阶段自动修复

如果你的代码已经进入CI/CD流程，我建议在构建阶段加一道"保险"，彻底不让^M流到后面的环节。

以GitLab CI为例，可以在before_script里加一个全局清理：

yaml复制before_script:
  - find . -type f \( -name "*.sh" -o -name "*.py" \) -exec sed -i 's/\r$//' {} +

也可以用dos2unix：

yaml复制before_script:
  - apt-get update && apt-get install -y dos2unix
  - find . -name "*.sh" -exec dos2unix {} \;

这样的话，即使有人在Windows上把文件提交上来了，CI构建时也会自动修复，不会因为换行问题中断整个发布流程。

7.4 一个容易忽略的点：Makefile

很多项目里会有Makefile，如果有人用Windows查了一下代码，无意间用记事本保存了一下Makefile，上传后make会报一些奇怪的错误，比如missing separator。这也是\r引发的。

这类文件同样需要纳入换行符治理范围。Git的.gitattributes里对Makefile指定eol=lf，不要漏掉。

7.5 shell脚本开头为何必须用LF

最后再聊一个小知识点：为什么Shell脚本对换行符这么敏感？

因为Unix内核在执行脚本时，会读取脚本第一行、以#!开头的那一行，把后面的内容当成"解释器路径"来解析。它没有做多余的空格或控制字符清理，所以一旦第一行末尾带着\r，内核就认为解释器路径是/bin/bash\r，自然找不到。

这跟Windows下.bat文件对CRLF的宽容态度完全不同。Linux内核这种"较真"的行为，其实是设计使然——它是一种安全性、确定性的体现，宁可报错也不猜。

8. 一个降维打击的小技巧：写脚本时直接用printf生成文件

如果你是在Linux服务器上临时创建一个脚本文件，但又不想被Windows的换行符问题绑架，有一个很实用的小技巧：不要用FTP上传，而是直接在Linux上通过cat或printf把内容写进去。

比如：

bash复制cat > deploy.sh << 'EOF'
#!/bin/bash
echo "hello"
EOF

这种方式用Here Document生成的文件，换行符完全取决于你终端输入的换行符，在Linux下就是\n，根本不会有^M问题。

也有人喜欢用printf一步步写，但我觉得那太累了，cat << 'EOF'就够用了。注意加上引号，防止变量展开。

我这几年维护服务器，凡是临时改脚本，基本都在服务器上直接编辑，不来回倒文件。这从源头上省掉了一大堆换行符、编码、权限的破事。

9. 写在最后的个人体会

这次排查/bin/bash^M的经历，其实特别有代表性。很多"莫名其妙的报错"，表面上看得一头雾水，但追根溯源之后，往往就是一个非常朴素的原理——文本文件在不同系统间的编码与换行差异。

我个人在踩过几次坑之后，现在固定下来的工作习惯就是三句话：

第一，所有跨平台文本文件，统一以LF为存储标准，用gitattributes和编辑器配置兜底。第二，上传到Linux的脚本文件，执行前用cat -A快速体检一遍，有^M就顺手清理。第三，临时修改的脚本，直接在服务器上用cat或vim写，不搞FTP来回传。

这套习惯执行下来，我几乎再没遇到过bad interpreter这类问题。每次看到团队里有新同学被^M折磨，我都把这几个命令发给他：cat -A、dos2unix、sed -i 's/\r$//'。东西不多，但真能救命。

希望这篇文章能帮你在下一次遇到^M时，不再一头雾水。祝你的脚本一次跑通。