1. 从一次线上部署翻车说起/bin/sh^M 到底是什么你大概率是在 Windows 上用编辑器写完一个.sh脚本通过 SFTP、Git 或者共享目录丢到 Linux 服务器上然后chmod x给了执行权限满心期待地敲下./deploy.sh结果终端甩回来一句bash: ./deploy.sh: /bin/sh^M: bad interpreter: No such file or directory第一次看到这个报错的人往往会懵/bin/sh明明存在啊ls -l /bin/sh也能看到它为什么说找不到关键就在那个^M上。^M是控制字符\r回车符Carriage ReturnASCII 码 0x0D在终端里的可视化表示。Windows 系编辑器默认用 CRLF\r\n作为行尾而 Linux/Unix 只认 LF\n。当内核去解析脚本第一行的 shebang 时它读到的不是/bin/sh而是/bin/sh\r于是它真的会去找一个名字里带回车符的解释器文件——当然找不到就报了No such file or directory。这个问题的迷惑性在于报错信息指向的是「解释器不存在」但真正的问题在「换行符格式」。如果你顺着报错去查/bin/sh是否存在、去重装 bash方向就完全跑偏了。我见过有同事为此重装了系统自带的 shell 包折腾半小时才发现是文件格式问题。它影响的场景非常广CI/CD 流水线里从 Windows 开发机提交的构建脚本、运维从 Windows 远程桌面拖上去的启动脚本、Docker 构建上下文里混入的.sh、甚至某些代码生成工具在 Windows 上产出的脚本。只要文件经过了 Windows 环境的编辑或传输就有概率带上 CRLF。这篇内容面向的是需要在 Linux 上稳定跑脚本的开发者、运维和测试同学。我会把「怎么确认是换行符问题」「怎么修」「修完怎么验证」这条链路讲透并且结合在 TaoToken 这类大模型 API 平台上做自动化脚本调用的实际场景给出一份可以直接照着做的排查清单。核心检索词就是linux sh脚本 bad interpreter No such file or directory你遇到的就是它。先说结论修复方式有三种——用dos2unix一键转换、用sed去掉\r、或者在编辑器里手动改文件格式。但在此之前你得先学会确认问题而不是猜。2. 动手前先确认用 file 和 od 定位 CRLF 换行符在动手改文件之前先做检测。这一步能帮你排除「其实不是换行符问题」的情况比如 shebang 路径真的写错了、文件根本没有执行权限、或者脚本第一行是空行。检测命令很简单但信息量很大。2.1 用 file 命令一眼看穿文件格式file命令会读取文件内容并给出类型判断对文本文件它会顺带告诉你行尾风格file deploy.sh如果输出里带CRLF基本就实锤了deploy.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators对比一个正常的 Linux 脚本输出是这样的deploy.sh: Bourne-Again shell script, ASCII text executable注意with CRLF line terminators这个后缀它就是罪魁祸首的标签。如果file输出里没有 CRLF 字样那你的bad interpreter报错可能是别的原因比如 shebang 写成了#!/bin/sh末尾多了空格或者#! /bin/sh#!和路径之间有空格某些内核不认。2.2 用 od 精确看到那个 \r 字符file给的是结论od给的是证据。想看第一行到底长什么样用八进制 dumpod -c deploy.sh | head -3输出大概是这样0000000 # ! / b i n / s h \r \n e c h o \r 0000020 \n e c h o h e l l o \r \n看到\r \n连在一起了吗这就是 CRLF。正常的 Unix 文件这里只会是\n。od -c会把每个字节按字符形式展示控制字符用反斜杠转义所以\r和\n都无所遁形。如果你只想看第一行shebang 所在行可以配合head和odhead -1 deploy.sh | od -c输出0000000 # ! / b i n / s h \r \n 0000007/bin/sh后面紧跟\r然后才是\n。内核解析 shebang 时读到\r就当成路径的一部分了于是去找/bin/sh\r报No such file or directory。这就是报错信息的完整来源。2.3 顺手检查 shebang 和权限检测换行符的同时把这两个也确认了避免修完格式还是跑不起来head -1 deploy.sh # 看 shebang 是否正确 ls -l deploy.sh # 看是否有执行权限shebang 的正确写法是#!/bin/bash或#!/bin/sh#!必须在前两个字节路径和#!之间不能有空格。权限方面-rw-r--r--表示没有执行位需要chmod x。这两个检查花不了几秒但能省掉「改完格式还是报错」的二次困惑。提示如果你在 TaoToken 的 Coding Plan 场景里用脚本自动调用 API脚本往往是从本地 Windows 环境同步到 Linux 构建机的这类跨平台同步最容易带上 CRLF。养成「同步后先 file 一下」的习惯能省很多事。检测做完问题定位清楚了接下来就是修。三种方法按你的环境选。3. 三种修法实测dos2unix、sed 与编辑器转换修复 CRLF 的核心思路就一个把\r\n变成\n也就是删掉每行末尾的\r。方法有轻有重我按「推荐程度」排一下你可以直接抄。3.1 首选 dos2unix一条命令搞定dos2unix是专门干这个的工具语义清晰还能保留文件权限和时间戳的合理行为。用法dos2unix deploy.sh如果系统没装先装# Debian/Ubuntu sudo apt-get install -y dos2unix # CentOS/RHEL sudo yum install -y dos2unix批量转换整个目录下的脚本find ./scripts -name *.sh -exec dos2unix {} \;dos2unix默认会直接修改原文件in-place转换后会打印每个文件处理了多少行。它还有个反向工具unix2dos如果你需要把 Linux 脚本传回 Windows 编辑可以用它转回去。实测下来dos2unix是最不容易出错的方式因为它就是为这个场景设计的。3.2 备选 sed不装工具也能修有些生产环境不允许随便装包或者你只是想快速验证这时候sed就派上用场了。去掉行尾的\rsed -i s/\r$// deploy.sh解释一下s/\r$//表示把每行末尾$的\r替换成空。-i表示直接改原文件。如果你不放心可以先不加-i把结果打到终端看看sed s/\r$// deploy.sh | head -5确认没问题再加-i落盘。批量处理find ./scripts -name *.sh -exec sed -i s/\r$// {} \;注意macOS 自带的sed对-i参数要求跟 GNU sed 不同需要写成sed -i s/\r$// deploy.sh。如果你在 Mac 上操作记得加那个空字符串参数。3.3 编辑器转换vi/vim 的 set ff如果你习惯在服务器上用 vim 直接改可以用它的文件格式设置。打开文件vi deploy.sh在命令模式下输入:set ff它会显示fileformatdos或fileformatunix。如果是 dos改成 unix:set ffunix然后保存退出:wq这样 vim 会把整个文件的 CRLF 转成 LF。这个方法的好处是不依赖外部工具坏处是文件大了之后手动操作略慢而且容易忘记:wq。3.4 三种方法怎么选方法适用场景是否需装工具批量能力dos2unix日常首选语义清晰需要强配合 findsed -i临时环境、无法装包不需要强配合 findvim :set ff单文件快速改不需要弱三种方法效果等价选一个顺手的就行。修完之后别急着跑先验证格式确实变了。4. 修复后验证重新执行脚本并确认结果改完格式不代表万事大吉得验证两件事文件格式真的变成 LF 了脚本真的能跑起来。4.1 再次用 file 确认格式file deploy.sh现在应该输出deploy.sh: Bourne-Again shell script, ASCII text executablewith CRLF line terminators消失了说明转换成功。再用od看一眼第一行head -1 deploy.sh | od -c输出应该是0000000 # ! / b i n / s h \n 0000007\r没了只剩\n。这一步确认了 shebang 行是干净的。4.2 确认执行权限并运行chmod x deploy.sh ./deploy.sh如果脚本本身逻辑没问题这时候应该正常输出结果。假设你的脚本内容是#!/bin/bash echo start deploy echo current dir: $(pwd)运行后应该看到start deploy current dir: /home/youruser4.3 在 TaoToken 自动化场景里验证 API 调用脚本如果你的脚本是用来调用大模型 API 的比如在 CI 里跑一个批量请求脚本修复格式后可以这样验证。先确认脚本里用的是正确的 Base URL 和 Key 环境变量#!/bin/bash export TAOTOKEN_API_KEY你的Key curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: claude-3-5-sonnet, messages: [{role: user, content: ping}] } | head -c 300注意这里的 Base URL 用的是https://taotoken.net/api不带任何多余路径。脚本跑通后你会看到返回的 JSON 里带choices字段。如果脚本因为 CRLF 跑不起来你连这个请求都发不出去所以格式修复是自动化链路的第一环。提示在 Coding Plan 这类长期编码场景里建议把「脚本格式检查」写进 CI 的 pre-commit 钩子用file或grep -l $\r提前拦截 CRLF 文件避免问题流到部署阶段。验证通过脚本能正常执行问题就算解决了。但实际排查中你可能会遇到一些「看起来像但实际不是」的报错下面单独拎出来讲。5. 常见报错对照排查401、local proxy failed 与 OAuthbad interpreter只是换行符问题的一种表现实际工作中还有几个高频报错容易和它混淆或者在你修完格式后冒出来。我按真实遇到的顺序列一下。5.1 报错还是 bad interpreter但 file 显示是 LF这种情况通常是 shebang 本身写错了。检查三种常见错误# 错误1路径和 #! 之间有空格 #! /bin/bash # 错误2末尾多了空格 #!/bin/bash # 错误3路径根本不存在 #!/bin/shh用head -1 deploy.sh | od -c逐字节看任何多余的空格、制表符都会暴露。正确的 shebang 必须是#!紧跟解释器绝对路径中间无空格行尾无多余字符。5.2 脚本能跑了但 API 请求返回 401格式修好后脚本执行成功但调用 TaoToken API 时返回 401 Unauthorized。这跟换行符无关是鉴权问题。排查顺序# 1. 确认 Key 环境变量已导出 echo $TAOTOKEN_API_KEY # 2. 确认请求头格式正确 # Authorization: Bearer keyBearer 和 key 之间一个空格 # 3. 确认 Base URL 正确 # https://taotoken.net/api401 最常见的原因是 Key 没读到环境变量在子 shell 里丢了或者 Key 前后带了空格/换行。如果你是从 Windows 复制 Key 到脚本里注意别把\r也复制进去了——这又绕回换行符问题了。可以在脚本里加一句清理export TAOTOKEN_API_KEY$(echo $TAOTOKEN_API_KEY | tr -d \r\n)5.3 local proxy failed 类报错有些环境会配置本地代理来转发 API 请求如果代理没起来或者端口不对会报local proxy failed或连接被拒绝。这类报错跟脚本格式无关检查代理进程是否在跑、端口是否被占用ss -tlnp | grep 你的代理端口需要说明的是这里说的代理是应用层的请求转发服务跟网络访问方式无关。如果你在 TaoToken 的接入文档里看到推荐的请求方式直接按文档配置 Base URL 即可不需要额外的转发层。5.4 返回 JSON 里读不到 choices 字段脚本跑通了HTTP 200但解析返回时发现没有choices。可能原因请求体里的model字段拼错了服务端返回了错误结构messages格式不对比如少了role或content返回的其实是错误信息被你的脚本吞掉了调试时先把原始返回打出来curl -s ... | tee /tmp/resp.json cat /tmp/resp.json | head -c 500看到原始 JSON 再判断。如果返回里有error字段按错误信息处理如果有choices那就是解析逻辑的问题。5.5 OAuth 相关报错如果你用的是需要 OAuth 授权的客户端比如某些 CLI 工具报错可能长这样OAuth token expired或invalid_grant。这跟脚本换行符无关是令牌过期或授权配置问题。重新走一遍授权流程或者检查令牌文件路径是否正确。在 TaoToken 的 ClaudeCodeAnthropic 接入场景里如果用到 OAuth 流程确保回调地址和客户端配置一致。5.6 排查清单速查表报错关键词大概率原因第一步动作bad interpreter ^MCRLF 换行符file确认dos2unix修复bad interpreter 无 ^Mshebang 写错head -1 | od -c逐字节看401 UnauthorizedKey 缺失/带空格echo $KEYtr -d \r\nlocal proxy failed转发服务未启动检查进程和端口无 choices 字段请求体格式错打印原始返回 JSONOAuth invalid_grant令牌过期重新授权把这张表存下来下次遇到报错先对号入座能省不少搜索时间。6. 把脚本格式检查固化进你的工作流修一次 CRLF 不难难的是每次都记得检查。我的做法是把格式检查前置到提交和构建环节让机器帮你拦。在 Git 仓库里加一个.gitattributes强制 shell 脚本用 LF*.sh text eollf这样即使你在 Windows 上编辑Git 提交时也会自动转成 LF从源头杜绝 CRLF 进入仓库。如果团队里有人用 Windows 开发这一条几乎是必配的。再在 CI 里加一道检查发现 CRLF 直接失败if file scripts/*.sh | grep -q CRLF; then echo 检测到 CRLF 换行符请用 dos2unix 转换后再提交 exit 1 fi本地也可以配个 pre-commit 钩子提交前自动跑dos2unix。这样你就不用靠记忆去防这个问题了。回到 TaoToken 的使用场景如果你在 Coding Plan 里让模型帮你生成 shell 脚本生成结果默认是 LF 的但如果你把脚本下载到 Windows 再传回 Linux中间就可能被编辑器改成 CRLF。所以「生成 → 传输 → 执行」这条链路上传输环节是风险点。养成传输后file一下的习惯比事后排查高效得多。需要 Key 和接入细节的话可以直接去 API Keys 页面拿接入文档里有各语言的完整示例。如果你主要是长期做编码和 Agent 自动化Coding Plan 会更合适只是想先验证模型返回用模型对话页面点几下就能看到结果。脚本格式修好之后这些接入动作才能真正跑起来——毕竟一个带^M的脚本连第一步请求都发不出去。