Shell脚本中curl命令退出码异常问题求助

这个问题我之前也碰到过，本质是不同Shell对扩展重定向语法的支持差异，咱们一步步拆解来看：

为什么会出现这种矛盾的现象？ #

当你用sh script_name.sh运行脚本时，这里的sh大概率是系统默认的POSIX标准兼容Shell（比如很多Linux发行版里是dash，而非bash）。POSIX Shell并不支持&>/dev/null这种合并重定向的简写语法——它会把这个写法拆成两个独立操作：

1. curl 127.0.0.1:5000 &：把curl命令丢到后台运行，脚本不会等待它执行完成
2. >/dev/null：这是一个空命令（什么逻辑都不执行），只是把标准输出重定向到/dev/null，这个空命令的退出码永远是0

所以你的脚本里拿到的“成功退出码0”，其实是空命令的结果，根本不是后台curl的真实退出码——这就造成了“明明连接失败，却显示成功”的错觉。

而当你改用zsh script_name.sh时，zsh支持&>/dev/null这个扩展语法，它会正确将curl的标准输出和标准错误都重定向到/dev/null，同时curl在前台运行，脚本能准确获取到它的真实退出码（连接被拒绝时为1）。

至于移除重定向后脚本能正常识别失败，是因为此时不管用什么Shell，curl都是在前台执行的，脚本自然能拿到它的真实退出状态。

解决办法 #

如果你希望脚本在任意POSIX兼容Shell下都能稳定运行，建议使用POSIX标准的合并重定向写法替代&>/dev/null：

curl 127.0.0.1:5000 >/dev/null 2>&1

这个写法的逻辑是：先把标准输出（文件描述符1）重定向到/dev/null，再把标准错误（文件描述符2）重定向到和标准输出相同的位置，实现和&>/dev/null完全一致的效果，而且所有符合POSIX标准的Shell都能识别。

如果你想保留&>/dev/null的简洁写法，可以在脚本开头加上Shebang行，明确指定用zsh或bash来执行：

#!/usr/bin/env zsh

或者

#!/usr/bin/env bash

这样不管用户是用sh运行，还是直接执行脚本，都会用你指定的Shell来解析，避免语法兼容问题。

内容的提问来源于stack exchange，提问作者jeanjo