Linux Shell Bash 带有特殊含义的退出码
表格 D-1. "保留的"退出码
退出码的值 | 含义 | 例子 | 注释 |
---|---|---|---|
1 | 通用错误 | let "var1 = 1/0" | 各种各样的错误都可能使用这个退出码, 比如"除0错误" |
2 | shell内建命令使用错误(Bash文档上有说明) | 很少看到, 通常情况下退出码都为1 | |
126 | 命令调用不能执行 | 程序或命令的权限是不可执行的 | |
127 | "command not found" | 估计是$PATH 不对, 或者是拼写错误 | |
128 | exit的参数错误 | exit 3.14159 | exit只能以整数作为参数, 范围是0 - 255(见脚注) |
128+n | 信号"n"的致命错误 | kill -9 脚本的$PPID | $? 返回137(128 + 9) |
130 | 用Control-C来结束脚本 | Control-C是信号2的致命错误, (130 = 128 + 2, 见上边) | |
255* | 超出范围的退出状态 | exit -1 | exit命令只能够接受范围是0 - 255的整数作为参数 |
通过上面的表, 我们了解到, 退出码1 - 2, 126 - 165, 和255 [1] 都具有特殊的含义, 因此应该避免使用用户指定的退出参数. 如果脚本使用exit 127作为退出语句, 那么可能就会在故障诊断的时候产生混淆(如何判断这是由"command not found"引起的, 还是由用户定义引起的?). 然而, 许多脚本使用exit 1作为通用的返回错误值. 因为退出码1能够表示的错误太多了, 不过这么做, 对于调试来说, 也起不到任何帮助的作用.
其实早就有人对退出状态值进行了系统的分类(请参考/usr/include/sysexits.h), 不过这个文件是为C/C++程序员准备的. 其实shell脚本也需要这样一个类似的标准. 所以本文作者呼吁限制使用用户定义的退出码, 尤其是范围64 - 113(还有0, 表示成功), 这么做, 就可以和C/C++标准保持一致. 这样我们就有了50个可用的退出码, 而且非常便于故障诊断.
本书中所有例子中的用户定义退出码都符合这个标准, 除了那些超出标准范围的例子, 比如例子 9-2.
![]() | 只有在Bash或sh提示符下, 当shell脚本退出后, 在命令行上使用$?才会得到与上表相一致的结果. 在某些情况下, 运行C-shell或者tcsh可能会给出不同的值. |
注意事项
posted on 2010-01-11 11:29 SYSTEM ADMINISTRATION 阅读(9030) 评论(0) 编辑 收藏 举报
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列:基于图像分类模型对图像进行分类
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 25岁的心里话
· 闲置电脑爆改个人服务器(超详细) #公网映射 #Vmware虚拟网络编辑器
· 零经验选手,Compose 一天开发一款小游戏!
· 通过 API 将Deepseek响应流式内容输出到前端
· AI Agent开发,如何调用三方的API Function,是通过提示词来发起调用的吗