1. 从一次“文件明明在却报 No such file or directory”说起你大概率遇到过这种场景脚本文件就在当前目录ls -l看得见chmod x也给了执行权限结果一敲./deploy.sh终端冷冰冰甩回来一句bash: ./deploy.sh: No such file or directory。更迷惑的是用sh deploy.sh有时能跑有时又报同样的错。这个报错在 Linux 下属于“名不副实”的典型——它说的“文件不存在”往往不是文件真的没了而是内核找不到能解释这个文件的那一行“开头”。先把结论摆前面Linux 执行.sh报No such file or directory绝大多数情况逃不出四类原因——换行符是 Windows 的 CRLF、文件带了 UTF-8 BOM 头、shebang 指向的解释器路径不存在、以及挂载参数或权限位把执行拦住了。这篇就按“先定位、再修复、后验证”的顺序把每一类的诊断命令和修复配置都给你写全照着敲就能复现和解决。适合谁看刚把 Windows 上写好的脚本传到 Linux 服务器的同学、用 CI/CD 跑构建脚本却卡在第一步的运维、以及被bash -x之前那行报错劝退的开发者。核心检索词就是Linux 执行 sh 文件提示 No such file or directory 的排查与解决方法下面所有命令都可以直接复制。我试过最坑的一次是脚本从 Git 仓库拉下来.gitattributes没配好core.autocrlf把 LF 又转回了 CRLF本地测试全过一到服务器就炸。所以别急着怀疑权限先按顺序把“文件本身长什么样”看清楚。2. 排查前置用 file、od、readelf 把脚本“验明正身”在动手改任何东西之前先做无损诊断。这一步的目标是回答三个问题文件是什么编码、换行符是什么、shebang 指向的解释器在不在。三条命令基本能覆盖。第一条file看文件类型和编码线索file deploy.sh正常应该是POSIX shell script, ASCII text executable或Bourne-Again shell script, UTF-8 Unicode text executable。如果输出里出现with CRLF line terminators那基本锁定换行符问题出现with BOM则是 BOM 头作祟。第二条od看开头几个字节专治 BOM 和隐藏字符od -c deploy.sh | head -3如果第一行开头是357 273 277八进制对应十六进制的EF BB BF这就是 UTF-8 BOM。BOM 会让内核把#!/bin/bash读成\xEF\xBB\xBF#!/bin/bash解释器路径自然找不到于是报No such file or directory。第三条readelf或head -1看 shebanghead -1 deploy.sh readelf -h /bin/bash 2/dev/null | head -5head -1直接看第一行是不是#!/bin/bash、#!/usr/bin/env bash还是别的。然后用ls -l确认这个解释器真实存在ls -l /bin/bash /usr/bin/env如果 shebang 写的是#!/bin/sh但系统里/bin/sh是个指向不存在目标的软链接同样会报这个错。用readlink -f /bin/sh追一下最终指向。把这三步做完你手里就有了“病历”是 CRLF、是 BOM、还是解释器缺失。接下来对症下药。3. 可复制配置dos2unix、sed 与 vim 三套修复方案诊断清楚后修复其实很快。下面按问题类型给出可直接复制的配置和命令注意每套都包含“改完怎么确认”的步骤。换行符 CRLF 修复首选dos2unix# 安装Debian/Ubuntu sudo apt-get install -y dos2unix # 转换 dos2unix deploy.sh # 确认 file deploy.sh没有dos2unix权限时用sed原地替换sed -i s/\r$// deploy.sh注意sed -i在 macOS 上要写成sed -i Linux 服务器上一般不用。转换后再file一次CRLF字样应该消失。BOM 头修复同样可以用sed去掉开头的EF BB BFsed -i 1s/^\xEF\xBB\xBF// deploy.sh或者用vim打开后执行:set nobomb再:wq。验证方式od -c deploy.sh | head -1开头应该直接是#而不是357 273 277。vim 内一站式修复适合你已经在编辑器里:set ff 查看当前格式显示 fileformatdos 就是 CRLF :set ffunix 改成 LF :set nobomb 去掉 BOM :wq 保存退出如果你用 VS Code 或 JetBrains 系列右下角状态栏能直接切换CRLF/LF编码选UTF-8不要选UTF-8 with BOM。团队协作时建议在仓库根目录放一个.gitattributes从源头堵住*.sh text eollf这样无论谁在 Windows 上克隆.sh文件都会保持 LF省掉后面一堆排查。权限与挂载这块也要顺带确认。执行权限chmod ux deploy.sh ls -l deploy.sh如果脚本放在/mnt或网络挂载盘上还要看挂载参数有没有noexecmount | grep -E /mnt| /data输出里带noexec的话即使权限对也执行不了需要重新挂载去掉该参数或把脚本移到本地磁盘再跑。4. 验证请求用 bash -x 确认脚本真的跑起来了改完之后别急着上生产先用bash -x做一次带追踪的执行把每一步展开看bash -x ./deploy.sh-x会打印每条命令及其展开后的参数前面带号。如果第一行就报No such file or directory说明 shebang 或换行符还没修干净如果能进入脚本逻辑只是某条命令失败那就是脚本内部问题跟本文主题无关了。再补一个“解释器直连”验证绕过 shebang/bin/bash deploy.sh如果这样能跑、./deploy.sh不能跑问题一定在 shebang 或执行权限如果两者都报错回到第 2 节重新诊断文件本身。成功的结果长这样bash -x输出一串开头的追踪行脚本正常执行到结尾退出码为 0。你可以用下面这行确认退出码bash -x ./deploy.sh; echo exit$?exit0就是干净通过。如果脚本里有set -e中途任何一条命令失败都会立即退出这时结合-x的追踪行就能定位到具体哪一步。对于需要频繁跑脚本、还想顺带调模型或跑 Agent 的场景可以把执行环境统一到一套稳定的接入配置上。比如用 TaoToken 的 Coding Plan 做长期编码任务时把 Base URL、Key、Model ID 三件套写进项目配置脚本里调用就少踩环境不一致的坑。模型对话入口在 https://taotoken.net/api需要看接入细节可以走文档 https://taotoken.net/docKey 在 https://taotoken.net/api-keys 管理。这些属于顺带提一句核心还是把脚本本身修对。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth虽然本文主题是脚本执行报错但很多同学是在“脚本里调 API”时把两类错误混在一起。这里把几个高频报错和本文的No such file or directory做个对照避免你排查错方向。No such file or directory本文主题文件在但解释器找不到。对照第 2 节重点查 CRLF、BOM、shebang。修复用第 3 节的dos2unix/sed/vim。401 Unauthorized这是鉴权失败跟文件格式无关。检查 Key 是否写对、是否过期、请求头Authorization: Bearer key是否带上。如果你在脚本里用环境变量传 Key先echo $API_KEY确认非空。local proxy failed本地代理配置有问题。检查HTTP_PROXY/HTTPS_PROXY环境变量是否指向了不可用的地址脚本里unset掉再试。注意这类报错和文件执行无关别去改 shebang。reading choices相关报错通常是解析模型返回体时字段缺失属于调用侧问题。确认请求的 Model ID 和返回结构匹配别把不同模型的响应格式混用。OAuth报错令牌刷新或授权流程没走完。检查 token 文件路径、过期时间重新走一遍授权。这类问题在 Codex 的auth.json场景里常见确认auth.json里的字段完整、路径可读。如果你用的是 Claude Code 做脚本润色或生成接入时同样要写全三件套Base URL 填https://taotoken.net/apiKey 用你在控制台生成的Model ID 按文档选。缺任何一项都可能报鉴权或模型找不到的错而不是本文的No such file or directory。把两类问题分开看排查效率会高很多。再补一个容易忽略的点脚本里source了另一个文件而那个文件路径写的是相对路径切换工作目录后就找不到了也会报No such file or directory。用bash -x能看到source那行的实际展开路径对照确认即可。6. 把修复流程固化成习惯排查到这一步你应该已经能独立定位No such file or directory了。最后给一套可以固化的操作顺序下次遇到直接照做先file和od -c看文件真身再head -1和ls -l确认 shebang 与解释器然后按 CRLF/BOM/权限/挂载四类对症修复最后bash -x验证退出码。真正省事的做法是从源头控制.gitattributes里给*.sh锁死eollf编辑器统一用无 BOM 的 UTF-8脚本 shebang 优先写#!/usr/bin/env bash而不是硬编码路径。这样迁移到任何 Linux 环境基本不会再被这个报错拦住。需要把脚本执行和模型调用串起来跑自动化时接入配置可以参考 https://taotoken.net/api-keys 生成 Key文档在 https://taotoken.net/doc模型对话调试走 https://taotoken.net/api。把环境配稳脚本本身修对剩下的就是安心跑任务了。