🔑 Shell 里为什么要有 exit status
很多人刚学命令行时，只盯着命令有没有“输出”。这其实抓错重点了。对 Shell 来说，一条命令最重要的不只是打印了什么，而是它最后到底算“成功”还是“失败”。这个结果不会靠一句英文提示来判断，而是靠一个很小但非常关键的数字：exit status，也就是退出状态码。
这样设计不是为了学术优雅，而是为了让程序能接着程序说话。人类看得懂 “file not found”，机器不该去猜你这句英文是什么意思。于是 Unix 很早就定了个朴素规则：命令结束时交一个整数出来，0 表示成功，非 0 表示失败。Shell 再根据这个数字决定后面该不该继续执行，比如
这里最容易踩坑的地方是：有输出，不等于成功；没输出，也不等于失败。比如
你可以把 exit status 理解成命令行世界里最基础的协议。输出是给人看的，状态码是给系统接线用的。没有这个约定，自动化脚本、CI、部署流程都会变成一堆脆弱的字符串匹配，稍微换个报错文案就全废了。
🧪 课后一题：执行
💡 易混淆点：
#CS
很多人刚学命令行时，只盯着命令有没有“输出”。这其实抓错重点了。对 Shell 来说，一条命令最重要的不只是打印了什么，而是它最后到底算“成功”还是“失败”。这个结果不会靠一句英文提示来判断，而是靠一个很小但非常关键的数字：exit status，也就是退出状态码。
这样设计不是为了学术优雅，而是为了让程序能接着程序说话。人类看得懂 “file not found”，机器不该去猜你这句英文是什么意思。于是 Unix 很早就定了个朴素规则：命令结束时交一个整数出来，0 表示成功，非 0 表示失败。Shell 再根据这个数字决定后面该不该继续执行，比如
cmd1 && cmd2 只有在 cmd1 成功时才跑 cmd2，而 cmd1 || cmd2 则是在 cmd1 失败时才补上第二个命令。你平时觉得这些符号顺手，背后靠的就是 exit status，而不是输出文字。这里最容易踩坑的地方是：有输出，不等于成功；没输出，也不等于失败。比如
grep pattern file 找到了会返回 0，没找到常常返回 1，但这不代表程序坏了，只是“没匹配到”。再比如有些命令明明打印了一堆错误信息，如果你不检查 $?，或者不把它放进 &&、||、脚本的错误控制里，Shell 还是可能继续往下跑，把后续步骤也一起搞脏。更坑的是管道。很多人以为 cmd1 | cmd2 里只要前面炸了，整个就算失败；实际上默认情况下，Shell 往往只看最后一个命令的退出状态。所以前面已经出错，后面命令如果照样退出 0，你会得到一个“表面成功”的假象。这就是为什么写严肃脚本时常要加 set -e，甚至 set -o pipefail：不是为了显得专业，是为了别让错误悄悄溜过去。你可以把 exit status 理解成命令行世界里最基础的协议。输出是给人看的，状态码是给系统接线用的。没有这个约定，自动化脚本、CI、部署流程都会变成一堆脆弱的字符串匹配，稍微换个报错文案就全废了。
🧪 课后一题：执行
false && echo ok || echo fail，终端最终会打印什么？为什么？答案：failfalse&&echo ok||echo fail💡 易混淆点：
0 在编程里常像“假”，但在 Shell 的 exit status 里，0 恰恰表示成功，非 0 才表示失败或特殊情况。#CS
