在Linux中,如果进程的退出状态为0,则认为该进程已正确完成。
我看到分割错误经常导致退出状态为11,尽管我不知道这只是我工作的地方的惯例(像这样失败的应用程序都是内部的)还是一种标准。
Linux中进程有标准的退出码吗?
在Linux中,如果进程的退出状态为0,则认为该进程已正确完成。
我看到分割错误经常导致退出状态为11,尽管我不知道这只是我工作的地方的惯例(像这样失败的应用程序都是内部的)还是一种标准。
Linux中进程有标准的退出码吗?
当前回答
第1部分:高级Bash脚本编写指南
像往常一样,高级Bash脚本编写指南有很多信息: (这个链接在另一个答案中,但指向一个非规范的URL。)
1:捕捉一般错误 2:误用shell内置程序(根据Bash文档) 126:调用的命令无法执行 127: "命令未找到" 128:退出的无效参数 128+n:致命错误信号“n” 255:退出状态超出范围(退出只接受0 - 255范围内的整数参数)
第2部分:sysexits.h
ABSG引用sysexits.h。
在Linux上:
$ find /usr -name sysexits.h
/usr/include/sysexits.h
$ cat /usr/include/sysexits.h
/*
* Copyright (c) 1987, 1993
* The Regents of the University of California. All rights reserved.
(A whole bunch of text left out.)
#define EX_OK 0 /* successful termination */
#define EX__BASE 64 /* base value for error messages */
#define EX_USAGE 64 /* command line usage error */
#define EX_DATAERR 65 /* data format error */
#define EX_NOINPUT 66 /* cannot open input */
#define EX_NOUSER 67 /* addressee unknown */
#define EX_NOHOST 68 /* host name unknown */
#define EX_UNAVAILABLE 69 /* service unavailable */
#define EX_SOFTWARE 70 /* internal software error */
#define EX_OSERR 71 /* system error (e.g., can't fork) */
#define EX_OSFILE 72 /* critical OS file missing */
#define EX_CANTCREAT 73 /* can't create (user) output file */
#define EX_IOERR 74 /* input/output error */
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
#define EX_PROTOCOL 76 /* remote error in protocol */
#define EX_NOPERM 77 /* permission denied */
#define EX_CONFIG 78 /* configuration error */
#define EX__MAX 78 /* maximum listed value */
其他回答
返回码的8位和终止信号的8位数字被混合成从wait(2) & co返回的单个值。
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>
int main() {
int status;
pid_t child = fork();
if (child <= 0)
exit(42);
waitpid(child, &status, 0);
if (WIFEXITED(status))
printf("first child exited with %u\n", WEXITSTATUS(status));
/* prints: "first child exited with 42" */
child = fork();
if (child <= 0)
kill(getpid(), SIGSEGV);
waitpid(child, &status, 0);
if (WIFSIGNALED(status))
printf("second child died with %u\n", WTERMSIG(status));
/* prints: "second child died with 11" */
}
你如何决定退出状态?传统上,shell只存储8位返回码,但如果进程异常终止,则设置高位。
$ sh -c 'exit 42'; echo $? 42 $ sh -c 'kill -SEGV $$'; echo $? Segmentation fault 139 $ expr 139 - 128 11
如果你看到的不是这个,那么程序可能有一个SIGSEGV信号处理程序,然后正常调用exit,所以它实际上没有被信号杀死。(程序可以选择处理除SIGKILL和SIGSTOP之外的任何信号。)
'1':笼统错误
'2':误用shell内置程序(根据Bash文档)
“126”:调用的命令无法执行
'127': "命令未找到"
'128':无效的退出参数
'128+n':致命错误信号"n"
'130':以Ctrl + C结束的脚本
255:超出范围的退出状态
这是给巴斯的。但是,对于其他应用程序,有不同的退出代码。
粗略地说,0代表成功,非0代表失败,1代表一般失败,大于1代表特定失败。除了false和test这两个简单的例外,我还发现了其他一些例外。
更现实地说,0意味着成功或可能失败,1意味着一般的失败或可能成功,2意味着一般的失败,如果1和0都用来表示成功,但也可能是成功。
如果比较的文件相同,diff命令给出0,如果不同,则给出1,如果二进制文件不同,则给出2。2也意味着失败。less命令为失败提供1,除非您未能提供参数,在这种情况下,尽管失败,它仍退出0。
more命令和spell命令给出1表示失败,除非失败是由于权限被拒绝、文件不存在或试图读取目录造成的。在任何这些情况下,尽管失败,它们仍然退出0。
然后expr命令给出1表示成功,除非输出是空字符串或零,在这种情况下,0表示成功。2和3是失败。
还有一些情况下,成功或失败是模棱两可的。当grep无法找到一个模式时,它退出1,但它退出2是真正的失败(比如拒绝许可)。Klist在找不到票时也会退出1,尽管这并不比grep找不到模式或ls一个空目录更失败。
因此,不幸的是,Unix的强大功能似乎并没有强制执行任何逻辑规则集,即使是在非常常用的可执行文件上。
程序返回一个16位的退出码。如果程序被一个信号杀死,那么高阶字节包含所使用的信号,否则低阶字节是程序员返回的退出状态。
退出码是如何分配给状态变量$的?然后到壳层。Bash保留状态的低7位,然后使用128 +(信号nr)表示信号。
程序的唯一“标准”约定是成功为0,错误为非0。使用的另一个约定是在错误时返回errno。
以前的答案都没有正确描述退出状态2。与他们声称的相反,状态2是您的命令行实用程序在不正确调用时实际返回的结果。(是的,一个答案可能是九年前的事了,得到了数百个赞,但仍然是错误的。)
下面是真正的,长期存在的正常终止的退出状态约定,即不是通过信号:
退出状态0:success 退出状态1:“失败”,由程序定义 退出状态2:命令行使用错误
例如,如果比较的文件相同,diff返回0,如果不同则返回1。根据长期以来的惯例,unix程序在被错误调用(未知选项,错误的参数数量等)时返回退出状态2。例如,diff -N, grep -Y或diff a b c都将导致$?被设置为2。这是自20世纪70年代Unix早期以来的实践。
接受的答案解释了当一个命令被一个信号终止时会发生什么。简而言之,由于未捕获信号而终止的结果是退出状态128+[<信号号>。例如,由SIGINT终止(信号2)导致退出状态130。
笔记
Several answers define exit status 2 as "Misuse of bash builtins". This applies only when bash (or a bash script) exits with status 2. Consider it a special case of incorrect usage error. In sysexits.h, mentioned in the most popular answer, exit status EX_USAGE ("command line usage error") is defined to be 64. But this does not reflect reality: I am not aware of any common Unix utility that returns 64 on incorrect invocation (examples welcome). Careful reading of the source code reveals that sysexits.h is aspirational, rather than a reflection of true usage: * This include file attempts to categorize possible error * exit statuses for system programs, notably delivermail * and the Berkeley network. * Error numbers begin at EX__BASE [64] to reduce the possibility of * clashing with other exit statuses that random programs may * already return. In other words, these definitions do not reflect the common practice at the time (1993) but were intentionally incompatible with it. More's the pity.