企业官网建设流程全解析

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看 shebang：

head -1 deploy.sh readelf -h /bin/bash 2>/dev/null | head -5

head -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 BF：

sed -i '1s/^\xEF\xBB\xBF//' deploy.sh

或者用vim打开后执行:set nobomb再:wq。验证方式：

od -c deploy.sh | head -1

开头应该直接是#而不是357 273 277。

vim 内一站式修复，适合你已经在编辑器里：

:set ff " 查看当前格式，显示 fileformat=dos 就是 CRLF :set ff=unix " 改成 LF :set nobomb " 去掉 BOM :wq " 保存退出

如果你用 VS Code 或 JetBrains 系列，右下角状态栏能直接切换CRLF/LF，编码选UTF-8（不要选UTF-8 with BOM）。团队协作时，建议在仓库根目录放一个.gitattributes，从源头堵住：

*.sh text eol=lf

这样无论谁在 Windows 上克隆，.sh文件都会保持 LF，省掉后面一堆排查。

权限与挂载这块也要顺带确认。执行权限：

chmod u+x deploy.sh ls -l deploy.sh

如果脚本放在/mnt或网络挂载盘上，还要看挂载参数有没有noexec：

mount | 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=$?"

exit=0就是干净通过。如果脚本里有set -e，中途任何一条命令失败都会立即退出，这时结合-x的追踪行就能定位到具体哪一步。

对于需要频繁跑脚本、还想顺带调模型或跑 Agent 的场景，可以把执行环境统一到一套稳定的接入配置上。比如用 TaoToken 的 Coding Plan 做长期编码任务时，把 Base URL、Key、Model ID 三件套写进项目配置，脚本里调用就少踩环境不一致的坑。模型对话入口在 https://taotoken.net/api，需要看接入细节可以走文档 https://taotoken.net/doc，Key 在 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/api，Key 用你在控制台生成的，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锁死eol=lf，编辑器统一用无 BOM 的 UTF-8，脚本 shebang 优先写#!/usr/bin/env bash而不是硬编码路径。这样迁移到任何 Linux 环境，基本不会再被这个报错拦住。

需要把脚本执行和模型调用串起来跑自动化时，接入配置可以参考 https://taotoken.net/api-keys 生成 Key，文档在 https://taotoken.net/doc，模型对话调试走 https://taotoken.net/api。把环境配稳，脚本本身修对，剩下的就是安心跑任务了。