Shell 脚本运行时修改引发的执行异常分析

在自动化运维或批量任务场景中，我们经常依赖多个 Shell 脚本来串联流程。比如主脚本 A 依赖子脚本 B，或者需要长时间休眠等待资源。这时候如果直接在终端里修改这些脚本文件，往往会遇到一些反直觉的行为。

对比一下编译型语言（如 C、Go），程序启动前已经生成了二进制可执行文件，运行时修改源代码是无效的。但 Shell 脚本本质上是纯文本，系统通过解释器逐行读取并执行。这意味着脚本文件的当前状态直接影响执行结果，但也埋下了隐患。

假设有一个简单的脚本 A.sh，没有依赖其他脚本：

#!/bin/bash
echo "start running"
sleep 30
echo "end running"

当脚本执行到 sleep 30 时，如果你用编辑器打开并修改了 A.sh 的内容（例如在中间插入一行命令），再次保存后，脚本通常会报错退出。

这是因为 Shell 解释器在启动时已经打开了该文件的文件描述符（File Descriptor）。虽然文件内容变了，但解释器内部维护的文件指针和 inode 信息可能不匹配，导致无法继续读取后续指令，甚至触发权限或完整性检查错误。

再看一个依赖场景。A.sh 调用 B.sh：

A.sh

#!/bin/bash
echo "start running"
sleep 30
sh B.sh
echo "end running"

B.sh

#!/bin/bash
echo "Here is B"

当 A.sh 进入 sleep 30 阶段时，此时它并没有加载 B.sh 的代码。如果你在休眠期间修改了 B.sh（例如增加了一行输出）：

#!/bin/bash
echo "Here is B"
echo "Hello B"

当 A.sh 唤醒并执行 sh B.sh 时，它会重新从磁盘读取 B.sh 的最新内容。因此，最终输出会包含修改后的结果。这说明子脚本是在每次调用时动态加载的，而非像主脚本那样持有初始句柄。

这个现象揭示了 Shell 脚本执行模型的一个关键特性：解释器对主脚本的持久化绑定。

在实际操作中，为了避免这种'互相污染'或执行中断的风险，建议遵循以下原则：

更多推荐文章