17 Shell游戏

为什么 Shell 游戏不可压缩

“会用命令”不等于“会把命令变成可靠工具”。临时在终端输入几行指令，通常能让当前操作者得到一个结果；一旦输入为空、文件名带空格、上游命令失败，或另一位同事需要在隔天重跑，真正的问题才显现：谁负责传递数据？失败在哪里被看见？成功是否只是最后一行输出看起来正常？

本单元把 Shell 看成一张小型工作台。小工具各自做一件窄事，连接处交代清楚输入和输出，脚本把边界、退出状态和恢复动作保存下来。这样做不是追求命令越短越好，而是让一段手工操作变成可解释、可重放、可审阅的流程。

本章的验收路线

先选一个低风险对象，例如扫描一批日志并统计某个事件。不要直接写“最终得到统计结果”，而要把过程拆成五站：命令行提供输入，管道传递筛选结果，退出码说明是否成功，幂等性约束重跑副作用，脚本证据把整次运行交给复核者。

下面的专属图示给出全景，实验台允许播放、暂停、单步和拖动进度。先预测：如果只拿掉退出码，哪一站应该先拒绝？再点击“注入单故障”，观察结果是否真的停在那个位置。

从一串命令到一条可复核的链

这条链不是把五个术语排成口号，而是给每个连接点一个问题。输入是什么？上游把什么交给下游？哪个状态可以让调用者拒绝继续？同一输入能不能重新跑？别人拿到哪些材料后可以复现？如果某个问题答不上来，Shell 只是替操作者记住了一组偶然的按键。

第一站：命令行冻结输入

先把路径、筛选条件、输出位置和危险动作写成参数，而不是藏在操作者的当前目录和记忆里。空输入也必须是一个可判断的情况：脚本可以接受并产生空报告，也可以明确退出，但不能把“没有匹配项”伪装成“扫描成功”。

第二站：管道缩小每个工具的责任

把大任务切成可以单独检查的小动作。过滤器只负责筛选，转换器只负责重排，汇总器只负责计算；每一段的标准输入、标准输出和标准错误都要有用途。需要保存原始数据时，用明确的重定向目标，不要依赖终端滚动区里的偶然文本。

第三站：退出码暴露状态

输出文本是给人看的，退出码是给调用者和自动化系统看的。一个命令可能打印了“没有结果”后仍正常结束，也可能写出部分文件后以非零状态退出。脚本应该在边界处检查状态，并决定是停止、跳过当前项还是进入恢复，而不是把最后一行漂亮的输出当成成功证明。

第四站：幂等性保护重跑

能重跑不只是“再按一次回车”。如果脚本每次运行都追加同一条记录、覆盖未经确认的文件，或把临时目录越堆越大，重跑会改变世界。设计时先说明目标状态，再选择覆盖、更新、跳过或拒绝；把重复执行当作正常测试样本，而不是运气好的偶发动作。

第五站：脚本证据交给别人

证据至少包含输入身份、工作目录、工具版本、关键参数、每个阶段的退出码、输出位置、失败原因和恢复动作。日志不必写成小说，但必须能回答“用什么输入，在什么边界，以什么状态结束”。可审计不等于泄露敏感数据；日志应记录标识和摘要，避免把令牌、密码或个人信息直接写入输出。

概念：五个边界如何互相约束

命令行 不是终端提示符本身，而是一次有身份的请求。把路径、筛选值和输出位置列出来，复核者才知道该从什么输入开始；把它们藏在环境变量或当前目录里，脚本就无法解释自己为何得到这个结果。

的价值在于缩小责任范围。每个命令只承诺处理一种输入，连接处再明确空流、坏行和错误流如何处理；管道越长，越需要在关键边界保留中间证据。

是机器可读的结论。它不替代人类可读的错误信息，却能让 CI、父脚本或监控知道是否继续。尤其要区分“没有匹配项”和“读取文件失败”，两者都可能没有普通输出，却不应有相同的处理策略。

决定证据落在哪里。将正常结果与错误信息分开保存，既便于复核，也能避免把故障信息混进下一条命令的输入；目标路径、权限和覆盖策略必须在脚本里显式说明。

不是所有 Shell 动作天然拥有的属性。查询通常容易做到幂等，追加写入和删除则需要去重键、存在性检查、确认边界或临时目录。先定义“最终状态”，再讨论怎样重跑，脚本才有安全的恢复路径。

把一次成功从个人记忆变成共享工件。它应保留足够的上下文来复核结论，也应过滤秘密和无关噪声；证据缺少首差位置时，失败只能靠猜。

提示26：发挥 Shell 命令的威力

提示26的重点不是熟记某个命令，而是组合小工具时保留清楚的契约。假设我们要从日志中抽取带有 WARN 的行，按日期排序后生成报告。先写验收合同：原始日志不被修改；没有匹配项要生成空报告并给出约定状态；读取失败必须停止；同一批日志重跑不会重复追加报告内容。

下面的短脚本把输入和输出命名出来，并为空输入保留一个可观察的分支。它仍然需要根据项目约定选择“空结果是成功还是特殊状态”，重点是不要让这一决定隐藏在管道末端。

#!/usr/bin/env bash
set -u
 
input=${1:?usage: $0 LOG_FILE OUT_FILE}
output=${2:?usage: $0 LOG_FILE OUT_FILE}
tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT
 
if ! awk '/WARN/ { print }' "$input" >"$tmp"; then
  printf '读取或筛选失败: %s\n' "$input" >&2
  exit 2
fi
 
sort -k1,1 "$tmp" >"$output"
printf '报告已生成: %s\n' "$output"

这里仍有可以继续收紧的地方：输出路径是否允许覆盖？排序键是否在所有日志格式中存在？磁盘写满时 sort 的退出状态能否被捕获？先把这些边界列为样本，再决定是否需要 set -o pipefail、临时文件原子替换或更严格的参数校验。Shell 的威力来自把这些选择显式化。

三步观察：从预测到恢复

用下面的分步图把五站压缩成三个复核动作。每一步都保留同一条工作流，只改变观察焦点；不要把图当作装饰，先说出预期首差，再看图中高亮的边界是否支持你的判断。

反例：看起来成功的管道

一个常见危险是前面的命令失败，后面的命令仍然读到空输入并正常结束。最终文件也许存在，终端甚至打印“完成”，但这只证明末端命令完成了自己的工作，不证明整条链拿到了正确数据。把每个阶段的状态写入脚本证据，或在明确的边界启用管道失败传播，才能让首差暴露出来。

另一个反例是直接把结果追加到正式报告。第一次运行产生一份报告，第二次运行把相同内容再写一遍；操作者看到的是“命令成功”，使用者看到的却是重复数据。先写临时文件、校验内容，再以原子方式替换目标，通常比边读边追加更容易恢复和审阅。

常见误区

可复查记录：一次 Shell 运行应留下什么

可以用一个小型记录描述运行，而不把它压缩成一个“可靠度分数”。字段的顺序对应故障定位顺序：

shell_run:
  input: logs/2026-08-08/service.log
  command: scan-warn --input "$input" --output report.txt
  working_directory: repository-root
  stages:
    - name: read
      exit: 0
    - name: filter
      exit: 0
    - name: sort-and-write
      exit: 0
  repeat_check: same_report_hash
  recovery: restore_input_and_replay
  secret_policy: redact_tokens

复核者拿到相同输入、命令版本和边界说明后，应能判断报告是否来自完整链路，而不是只看文件是否存在。若第二次运行的哈希不同，先比较第一处不同的阶段，再检查排序、时间戳或非确定性字段；不要用“最终看起来差不多”覆盖差异。

跨时代迁移：今天仍要重新验证什么

Shell 的小工具思路可以迁移到容器、CI、数据清洗和部署流水线，但环境差异会改变命令的含义。当前目录、默认 shell、字符集、权限、并发执行方式和工具版本都应成为输入的一部分。一个在个人终端运行的命令，不会因为被复制进 CI 就自动拥有同样的权限或文件布局。

自动生成命令也需要同样的审阅：保存生成前的意图、实际展开后的参数和失败样本；对会删除、覆盖或上传数据的动作，要求人工确认边界。工具可以减少敲键盘的时间，却不能替人决定什么状态算完成、什么信息可以写进日志。

本章回顾

• 命令行冻结输入，让手工动作变成可重放请求。
• 管道切分责任，连接处要说明空输入、错误流和退出状态。
• 幂等性把重复执行纳入设计，脚本证据让别人能够独立复核。
• 正常、空输入和故障样本共享其余条件，首个变化点才有解释力。
• Shell 的威力不在于命令更短，而在于每个小工具的契约可见、失败可定位、恢复可重放。

练习：把命令变成证据

名词解释

来源与改写范围

• 作者与英文版页面：核对 20 周年版书名、版本和 Topic 范围。
• 中文公开目录：核对“17 Shell游戏”和提示26的目录坐标。
• Bash 参考手册：核对 Shell 参数、重定向、管道和退出状态的现行语义边界。

前后导航

• 上一页：16 纯文本的威力
• 下一页：18 加强编辑能力