搞定这个需求之前先说一句大实话写shell脚本十年最让我血压升高的不是复杂的语法不是诡异的通配符展开而是这一行看起来人畜无害的调试命令——set -ex。尤其是当脚本里出现了grep而且目标文件里恰好什么都没有的时候你会看到一条非常迷幻的现象脚本突然中断返回状态码是1而不是你可能预期的0。第一次遇到这个问题时我盯着终端愣了半天逻辑上想不通不就搜了个空吗怎么就算错误了如果你也正在被这个状态码折磨或者你的CI流水线里脚本总是莫名其妙地“意外失败”那这篇内容就是写给你的。我会把原因拆透把解决方案给全再从实践经验里把那些文档里绝不会写的细节都翻出来。先回答标题里的问题这个现象不是bug是特性。grep在没有匹配内容时返回码约定就是1而不是0。而set -e的作用就是一旦任何一条命令返回非0整个脚本立即退出。两者撞在一起grep搜空结果 set -e 脚本“因无事发生而死亡”。如果你不理解这套底层约定就会觉得它在无理取闹理解了以后你会发现这其实是shell世界在逼你养成精确思维。1. 问题现场还原从一条“应该没问题”的grep开始1.1 先复现这个让你困惑的瞬间假设你手上有一个日志文件app.log想确认里面是否出现了ERROR关键字。于是你写了一个脚本#!/usr/bin/env bash set -ex grep ERROR /var/log/app.log echo 检查完成你知道app.log里当前没有ERROR日志你的本意是“查一下有没有错误然后继续往下走”输出一个“检查完成”再退出。但实际运行结果会让你大跌眼镜 grep ERROR /var/log/app.log Process exited with status code 1脚本在执行完grep之后直接停下了后面的echo 检查完成根本没执行。与此同时整个脚本的退出状态码就是1。如果你是在CI流水线里跑这种脚本流水线会直接标红报错信息却只有一行grep命令没有任何“检查完成”的输出。你翻遍日志也找不到异常堆栈因为压根没有异常只是grep“没找到东西”。这就是最常见的一种复现场景。很多初学者会立刻怀疑是不是文件路径写错了是不是权限问题其实都不是。把文件里的内容清空、把grep改成搜一个肯定存在的内容脚本就能正常运行。但这恰恰说明问题在于grep的“无匹配”这个返回值而不是脚本本身有逻辑错误。1.2 为什么第一反应是“0”而不是“1”人们的常见直觉是命令执行成功就返回0执行失败才返回非0。搜索一个文件没有找到内容这算什么失败呢什么也没发生程序正常跑完“没找到”不也是一种正常结果吗按这个逻辑grep返回0似乎是合理的。但这个直觉恰恰忽略了grep的设计初衷grep是一个过滤器它的存在意义就是“找到匹配内容并输出”。为了在脚本循环中方便地判断“是否找到”它把返回值设计成了三态返回码含义场景0找到了至少一个匹配搜索内容存在1没有找到任何匹配搜索内容不存在2执行出错文件不存在、无权限、参数错误等参数错误或IO失败注意只有在返回2的时候才表示“命令本身出问题了”。返回1只是表示“查询结果为空”这个状态和[ -f file ]判断文件不存在的逻辑是一模一样的。如果你在代码里写过if [ -f 某文件 ]; then ...; fi那你就应该能引申理解shell世界把所有“条件判断”都建立在退出码上grep返回1不是“命令出错”而是“条件为假”。可是set -e并不知道这个区别。它的大脑很简单非0就退出。它不会去想这个非0到底代表“出错”还是“条件不成立”只要不是0一律按“致命错误”处理。于是grep搜空结果触发了这个机制脚本卒。2. set -ex的真正含义与状态码传播逻辑2.1 把set -x和set -e拆开看很多人在脚本开头写set -ex但未必清楚每个字母的含义。我习惯做这样一个生活化类比set -x就像你开了一个“现场直播”每条命令在执行前先打印出来让你看清楚脚本正在干哪件事set -e则像一个“一踩到钉子就停下”的急停开关任何命令返回非零状态脚本立刻终止。具体来说set -xxtrace开启调试模式Shell会把每个即将执行的命令展开后输出到终端。比如变量FOObar命令echo $FOO会被打印成echo bar方便你确认实际执行的内容是什么。set -eerrexit开启错误即停模式。任何一条前台命令的退出状态码非0脚本就立即退出退出码沿用最后那条失败命令的状态码。set -ex就是把两者合体一边打印每一步的细节一边在出问题时立刻“翻车”。你可能会问开着set -e还要set -x有什么用其实set -x对你的排查问题至关重要。如果没有-x脚本在grep处静默退出你就只知道“状态码是1”但不知道卡在哪一行有了-x你会明确看到最后执行的命令就是grep ERROR /var/log/app.log定位问题就像从高清地图上找路而不是摸黑前行。2.2 退出码的传播路径现在我们把问题再往后推一步。你可能会想就算grep返回了1脚本退出了那这个退出状态码1到底是怎么落到整个脚本头上的Shell的执行模型决定了这一点一个脚本是一个进程它的最终退出状态码就是它执行的最后一条命令的退出状态码除非有exit命令显式指定。而当set -e触发时脚本直接终止不再往后执行任何命令那么这个进程的退出状态码就自动“继承”了触发者的状态码——也就是grep的1。用一个更直白的例子来感受它#!/usr/bin/env bash set -e false echo 这条不会执行当你运行这个脚本时返回状态码是1而不是0。因为false命令专门用来返回失败状态而set -e让整个脚本陪着一起失败。同理grep无匹配时返回1脚本也就整体“失败”了。这个机制中的逻辑链是这样的grep无匹配 - grep返回1 - set -e发现非0 - 脚本立即退出 - 脚本状态码继承为1如果脚本里没有set -egrep返回1之后脚本会往下继续执行最终状态码由echo 检查完成来决定也就是0。这也解释了一个矛盾现象很多人在本机测试时没有加set -e脚本看起来一切正常一旦把同样的脚本放到CI环境里CI配置通常要求加set -ex或者某些基础镜像默认加上了脚本就开始“毫无理由”地失败。3. 我踩过的坑真实场景里的三种“非预期死亡”3.1 场景一安全巡检脚本里查漏洞关键字之前我维护过一个自动巡检脚本逻辑是从系统日志里查敏感关键字查不到就说明安全状态良好然后打印一条“未发现风险”继续跑。一开始脚本长这样set -ex grep 危险操作 /var/log/audit.log echo 未发现风险当日志里确实没有“危险操作”字样时脚本总是异常退出状态码1。而我本人当时的预期是没发现应该算“好消息”脚本里后续的告警逻辑根本来不及执行。后来我在脚本里给grep加了|| true问题才解决。这个场景非常典型因为它暴露了一个心智模型上的根本矛盾grep的“非0返回”对于一个搜索任务来说是“空结果”但对于一个业务系统来说空结果可能是业务上的“成功”。所以用grep裸命令去承载业务逻辑本身就是一种脆弱设计。3.2 场景二检查配置项是否存在的初始化脚本另一个常踩的场景是服务初始化脚本。比如你要检查某个配置文件里是否设置了worker_processes参数决定要不要写入默认值set -ex if grep -q worker_processes /etc/myapp/config.conf; then echo 已配置 else echo 未配置写入默认值 echo worker_processes4 /etc/myapp/config.conf fi这里的grep写在if条件里奇怪的是它并不会导致脚本退出。为什么呢因为set -e有一个内置规则如果命令出现在if、while、until等条件判断的上下文中那么它的非0返回不会触发退出。这是set -e最容易被忽略的隐蔽规则之一后面我会专门展开。但如果有人没意识到这一点把同样的grep直接放在if外面用于“先查一下状态”再基于一个全局变量做判断那就会遇到场景一的问题。一个看似无害的改动就会让脚本在未配置的情况下直接“逃生”。3.3 场景三管道中的grep与pipefail的叠加效果再进阶一下这个坑在管道中会变得更有迷惑性。比如set -ex grep ERROR /var/log/app.log | head -10假设日志里没有ERRORgrep返回1。但这条命令的返回码其实取决于管道中最后一条命令head -10而head通常返回0。所以哪怕没有|| true脚本也不会退出。这看起来是“隧道尽头有光”但只要你再开启set -o pipefail很多生产环境镜像默认开启管道返回码就会取所有命令中的最大非零值此时脚本又会在管道的源头死掉。你看到报错时报错点却指向了head -10排错成本一下子就上来了。这个场景之所以特别坑是因为排查者会盯着head命令想破脑袋head怎么可能返回1但实际上罪魁祸首是管道上游的grep。我不止一次在群里看到有人贴这种执行日志求教每次都能引发一轮“猜猜谁害死了脚本”的头脑风暴。4. 解决问题的正规军场景化改造grep4.1 方案一grep ... || true显式声明“空结果可以接受”最快速直接的做法是给grep加一个兜底set -ex grep ERROR /var/log/app.log || true echo 检查完成这里的逻辑是如果grep返回非0就执行true命令而true永远返回0。于是grep ... || true这个复合命令的最终状态码就被“修正”为0set -e不会触发脚本可以继续执行。但代价是你同时丢弃了grep返回1和返回2的信息。如果文件根本不存在grep返回2你也会被|| true吞掉脚本继续跑问题被静默掩盖。所以这个方案的适用场景是你非常确信文件存在、权限没问题只是“有匹配无匹配都可以”并且后面不依赖grep的返回状态做任何判断。如果是要做条件分支贸然加|| true会埋下巨大隐患。4.2 方案二用if grep -q ...做逻辑分支如果你要根据结果执行不同逻辑正确的做法是把grep放进if条件里。这里引出一个关于set -e的关键细节set -e在命令作为条件判断比如if / while / until的一部分时不会因为其非0返回而退出。这个规则很多老手也未必能准确说出来。推荐写法if grep -q ERROR /var/log/app.log; then echo 发现ERROR else echo 没有ERROR fi注意我在这里用了grep -q的-q参数它的意思是“安静模式”只关心返回码不输出匹配内容。这样一来判断更快一旦找到匹配就停止读取而且不会在终端上刷出大量匹配行。在脚本逻辑判断场景里grep -q几乎总是优于裸grep。这种方法的好处是不触发set -e退出因为有if包裹逻辑清晰两种结果都显式处理不会丢失“文件不存在”的错误信息。因为grep返回2时if走else分支你可以在else里再单独判断文件是否存在从而区分“没找到”和“读取失败”。4.3 方案三自定义返回状态码自己掌握脚本命运如果你不仅需要判断“有没有”还要决定整个脚本最终的返回状态码那么你可以在脚本末尾用exit显式控制。这也是我认为最符合“精确控制”的做法#!/usr/bin/env bash set -ex RESULT$(grep ERROR /var/log/app.log || true) if [ -n $RESULT ]; then echo 发现ERROR异常退出 exit 1 else echo 无ERROR正常结束 exit 0 fi注意这里在命令替换里给grep追加了|| true防止RESULT$(grep ...)因为grep返回1而被set -e拦截。然后通过对变量的判断来区分两种业务结果最后显式声明退出状态码。这样一来你的脚本就不会被grep的状态码“绑架”了最终退出码完全由你自己的业务逻辑决定。在实际运维场景里这种写法特别适合那种“检查结果是干净的就继续有脏数据就报警退出”的脚本。4.4 方案四set e局部关闭错误即停机制还有一个更“灵活”但需要谨慎使用的方案临时关闭set -e。set -x set e grep ERROR /var/log/app.log grep_status$? set -e if [ $grep_status -eq 0 ]; then echo 找到了 else echo 没找到或出错 fi关键在于先用set e取消“错误即停”执行grep后立刻用$?捕获它的真实返回码然后再用set -e重新开启该机制。这里的实现细节非常值得注意grep_status$?这一行必须紧跟grep之后不能插入任何其他命令否则$?就变成了上一条命令的状态码前功尽弃。重新开启set -e之后后续的if判断、其他可能出错的命令依然会受保护。这个方法适合某段代码需要“容忍非0退出”的场景比给每个命令都加|| true更优雅。但我不建议把整个脚本都用set e包起来那样就失去了set -e的保护意义。局部关闭、用完立刻恢复才是正确姿态。4.5 方案五直接用awk、sed或变量判断替代grep有些场景真的没必要用grep。比如你其实只是在判断一个变量是不是非空或者想在一堆配置文本里检测某个键是否存在。能用shell内置能力解决的就不要启动一个外部进程脚本会更快、更不容易受状态码问题影响。判断一个变量是否为空if [ -n $FLAG ]; then echo FLAG已设置 else echo FLAG为空 fi检测配置文件中是否包含某项配合awk的退出机制if awk /worker_processes/{found1} END{exit !found} /etc/myapp/config.conf; then echo 配置存在 else echo 配置不存在 fiawk的逻辑同样是找到时返回0没找到时返回1。它在if条件里和grep扮演的角色一样但因为awk本身是文本处理工具你可以在同一段代码里顺便完成提取、统计等等工作避免一个检查步骤却需要多个命令串联的尴尬。5. 沿着“状态码”这根藤摸出set -e的更多瓜5.1 常见条件上下文与非条件上下文我前面提到set -e对if条件中的命令“网开一面”这个规则值得展开细说。下面这些场景中的命令即使返回非0也不会触发set -e退出if 命令; then中的命令while 命令; do中的命令until 命令; do中的命令由或||构成的复合命令的左端也就是连接符号之前的命令在!之后被逻辑取反的命令这最后一个尤其反直觉。比如set -e ! grep ERROR /var/log/app.log echo 继续执行如果grep返回1没找到!会把1取反为0整个命令的最终状态码是0脚本继续执行。如果grep返回0找到了!会把它取反为1脚本就会退出。这个行为和很多人的直觉相反如果你不加!脚本在“没找到”时退出加了!脚本反而在“找到”时退出。所以我经常建议团队里的人在写shell脚本时把grep和set -e的交互规则做一个最简单的记忆锚点凡是你不希望它“以非0杀死脚本”的命令要么放进if条件里要么用|| true或|| 处理动作来显式接管。不要靠运气去赌默认行为符合你的预期。5.2 命令替换中的grep还有一类问题也很隐蔽在命令替换里跑grep。比如set -e content$(grep ERROR /var/log/app.log) echo 执行完毕如果你以为这里grep没找到内容时脚本会退出那么在某些版本的Shell里你会猜对在某些版本里又会猜错。这个行为在不同Shell版本之间并不完全一致甚至在同一Shell的不同版本中也有差异。也就是说命令替换中的非0退出是否触发set -e取决于Shell版本和语境。这比裸grep坑多了。这种情况下最稳妥的解法依然是给grep加|| truecontent$(grep ERROR /var/log/app.log || true)从安全性和跨平台一致性出发我强烈建议在所有命令替换里对可能返回非0的命令加上显式兜底。把话说在前头——总会有人争论“某个版本的bash不用加也能过”但生产环境千变万化你的脚本很可能今天在bash 4.4跑得好好的明天部署到bash 3.2的机器上就开始出现诡异问题。写兼容性稳定的脚本就是要从这种细节入手。5.3grep -q的另一个陷阱意外返回2很多人都知道grep返回0和1的区别但容易忽略返回2。当你写grep -q ERROR /var/log/app.log而app.log不存在时grep返回的不是1而是2。如果你在if里判断if grep -q ERROR /var/log/app.log; then echo 找到 else echo 没找到 fi当文件不存在时你也会走到else分支输出“没找到”。但真相是“文件不存在”并不是“没找到”。业务含义完全不同。如果你需要严格区分这两种情况需要在else分支里再对文件存在性做一次判断if grep -q ERROR /var/log/app.log; then echo 找到ERROR elif [ -f /var/log/app.log ]; then echo 文件存在但没找到ERROR else echo 文件不存在 fi虽然多了一次文件系统调用但在排查生产问题时候把“没匹配”和“文件缺失”区分开能帮你节省大把时间。我就曾因为一个配置文件路径被误写成复数形式在监控脚本里反复看到“未发现非法请求”的提示根本没想到是路径错了导致grep根本没读文件。后来加上elif判断才然发现日志目录压根没对上。6. 一个完整的实战脚本从状态码泥潭里走出来6.1 引入一个真实需求假设你需要写一个部署前检查脚本用来判断应用配置目录下的flag.conf里是否设置了enable_cache。如果设置了就输出“缓存已启用”并继续部署如果没设置就输出“未启用缓存”同样继续部署如果配置文件压根不存在就输出错误信息并以状态码2退出。这个脚本的要求是整个脚本必须严格受set -e保护不能因为grep无匹配就翻车但也不能因为|| true掩盖文件缺失的严重故障。这几乎是生产环境里最典型的场景了一个必须继续执行但需要区分检查结果的脚本。6.2 实现与逐行解读#!/usr/bin/env bash set -eo pipefail CONFIG_FILE/etc/myapp/flag.conf set e grep -q enable_cache $CONFIG_FILE 2/dev/null grep_status$? set -e if [ $grep_status -eq 0 ]; then echo 检查结果缓存已启用 # 假装这里有一些依赖“缓存启用”的部署路径 echo 执行启用缓存的部署步骤... elif [ $grep_status -eq 1 ]; then echo 检查结果未启用缓存 # 假装这里走的是“未启用缓存”的部署路径 echo 执行默认部署步骤... else echo 错误配置文件不存在或无法读取 2 exit 2 fi echo 部署前检查完成继续执行后续任务逐行逻辑拆解set -eo pipefail是脚本安全基线开启了错误即停和管道错误传播。用set e临时关闭错误即停因为接下来要执行一个“可能返回非0但业务上不是错误”的命令。grep -q enable_cache $CONFIG_FILE 2/dev/null-q用来静默匹配2/dev/null把文件不存在等错误信息屏蔽掉因为我们后面会用返回码区分。grep_status$?立刻捕获返回码这是整个解密过程最关键的一行不允许在它之前插入任何命令。set -e重新开启错误即停让后续没被特殊保护的命令回到严格模式。三个分支分别处理返回码0、1、其他值。对于文件缺失返回码2我们主动exit 2把这种“严重的配置错误”以更有语义的状态码反馈给调用方。后续命令继续受set -e保护。在这个脚本里grep不再是一个“隐藏的杀手”而是变成了一个被我们主动读取状态的工具。你用它的返回码来驱动业务逻辑而不是让Shell隐式处理它的非0返回。6.3 执行效果实测假设flag.conf中不包含enable_cache运行结果检查结果未启用缓存 执行默认部署步骤... 部署前检查完成继续执行后续任务最终退出码是0。如果文件不存在错误配置文件不存在或无法读取最终退出码是2。这才是符合业务预期的行为。一个搜不到内容的grep就不再导致整个部署流程像多米诺骨牌一样哗啦啦倒下了。7. 构建更抗风险的shell脚本习惯7.1 计算一次代价grep返回值在你的脚本里值多少钱我在团队内部做分享时经常问一个问题一次grep返回1让你的CI流水线晚半小时才把真正的问题暴露出来这个代价大不大没人能说不大。很多生产事故的苗头恰恰是被这种“脚本莫名奇偶退出”掩盖的因为大家第一反应是去修脚本而不是去查业务数据。所以我的核心建议是在写脚本时把“这个命令可能返回什么状态码”当成和“这个命令输出什么内容”一样重要。尤其是涉及搜索、过滤、判断类命令时要养成给状态的强制习惯。7.2 九个实战避坑要诀我在实际项目里沉淀了一套检查清单每次写脚本都会过一遍脚本开头固定写set -eo pipefail除非有明确的理由放弃它。任何grep出现在非if上下文中都要问自己一句如果它返回1脚本该怎么走grep做判断时优先加-q只在需要输出匹配内容时才不加。用|| true处理“无匹配不算错”的场景但永远记住它会连同返回2一起吞掉。用if grep -q处理需要分支的场景简单又安全。用$?捕获返回码时确保没有在命令之间插入任何其他语句。对“有匹配”和“匹配为空”同时有业务意义时优先用不同退出码区分而不是一个布尔判断糊弄过去。所有读取外部文件的grep都要思考“文件不存在会怎样”。调试时开set -x但上线前可以保留也可以去掉它不影响逻辑。7.3 别让状态码吓住你而是把它变成信号最后说一个我自己的心法。Shell脚本和高级语言不一样它没有异常体系没有try-catch。它能用的唯一信号机制就是状态码。set -e把状态码变成了“紧急制动”而正确的状态码使用方式是把它当成“消息传递”而不是“生死判决”。grep返回1它只是在告诉你没有找到。这是信息不一定是事故。掌握了这一点以后你再回头看set -ex和grep的组合会觉得这套工具其实非常合理set -x帮你看见一切set -e帮你拦住意外grep的三态返回码帮你做出精确决策。真正需要修炼的是用状态码思考的习惯。我个人在实际操作中最喜欢的一个小技巧是给所有“可能空结果”的grep统一声明为函数seek() { local pattern$1 local file$2 if [ ! -f $file ]; then return 2 fi grep -q $pattern $file }然后在业务脚本里直接调用if seek ERROR /var/log/app.log; then。返回值三态清晰文件存在性也自动处理了代码还能复用。这个函数虽然简单但它逼着我把“空结果不是错误”的语义写进了代码结构里而不是靠每次小心地加|| true去碰运气。下一次你再遇到“grep搜索返回为空时set -ex返回状态码是1不是0”我希望你脑子里闪过的不是“这破脚本怎么回事”而是“哦又是我没有显式接管grep的返回状态”。想通这个你写的脚本就会从“能跑”进化到“扛得住折腾”。
