Существуют ли стандартные коды состояния выхода в Linux?

Процесс считается завершенным правильно в Linux, если его состояние выхода было 0.

Я видел, что ошибки сегментации часто приводят к состоянию выхода 11, хотя я не знаю, является ли это просто соглашением, в котором я работаю (приложения, которые потерпели неудачу, как все, были внутренними) или стандартом.

Существуют ли стандартные коды выхода для процессов в Linux?

 marinara21 окт. 2012 г., 19:56
если вы ищете «системный номер ошибки» возвращается системными функциями, смотрите здесьerrno

Ответы на вопрос(10)

Ни один из старых ответов не описывает правильное состояние выхода 2. Вопреки тому, что они утверждают,status 2 is what your command line utilities actually return when called improperly. (Да, ответ может быть девять лет, иметь сотни голосов, и все же быть неправильным.)

Вот реальное, давнее соглашение о статусе выхода для нормального завершения, то есть не по сигналу:

Exit status 0: success Exit status 1: "failure", as defined by the program Exit status 2: command line usage error

Например,diff возвращает 0, если сравниваемые файлы идентичны, и 1, если они различаются. По давним соглашениям программы Unix возвращаютсяexit status 2 when called incorrectly (unknown options, wrong number of arguments, etc.)  Например,diff -N, grep -Y или жеdiff a b c все приведет к$? устанавливается на 2. Это и было практикой с первых дней Unix в 1970-х.

принятый ответ объясняет, что происходит, когда командаterminated by a signal. Вкратце, завершение из-за необработанного сигнала приводит к состоянию выхода128+[<signal number>, Например, прекращениеSIGINT (сигнал 2) приводит к состоянию выхода 130.

Notes

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 oth­er 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.

 24 июл. 2018 г., 16:23
Если программа перехватывает SIGINT, очищается и в любом случае завершает работу, ее состояние будет таким, каким имеет смысл для программы. Например,more сбросит режимы терминала и выйдет со статусом 0 (вы можете попробовать).
 24 июл. 2018 г., 16:22
Оболочка, которая выполняет программу, не имеет значения; теоретически процесс может выбрать выход с различным статусом в зависимости от его родительского процесса, но я никогда не слышал о случае, когда это происходит.
 20 июл. 2018 г., 19:50
Что должна вернуть программа, когда онаdoes обрабатывать завершение, перехватывая SIGINT / Ctrl-C? Еще 130? Имеет ли значение другая оболочка, кроме bash?

'1' & GT; & GT; & GT; Catchall для общих ошибок

'2' & GT; & GT; & GT; Неправильное использование встроенных командных оболочек (согласно документации Bash)

'126'& GT; & GT; & GT; Вызванная команда не может быть выполнена

'127'& gt; & gt; & quot; команда не найдена & quot;

'128'& GT; & GT; & GT; Неверный аргумент для выхода

'128+n'& gt; & gt; & gt; сигнал фатальной ошибки & quot; n & quot;

'130'& GT; & GT; & GT; Сценарий прекращен с помощью Control-C

'255'& gt; & gt; & gt; Выход из состояния вне диапазона

Это для Баш. Однако для других приложений существуют разные коды выхода.

 09 июл. 2009 г., 07:39
+1 - это полезнее, чем просто вставить ссылку
 10 окт. 2016 г., 10:43
Это похоже на плагиат из АБС без указания авторства. (Мы можем сказать, потому что ABS содержит неверную или, по крайней мере, вводящую в заблуждение информацию.)
 03 сент. 2011 г., 20:44
Обратите внимание, что «контроль-С дает 130»; согласуется с «128 + n»; для сигнала n; control-C генерирует сигнал SIGINT, который является сигналом 2.
 Nathan Fellman09 июл. 2009 г., 07:37
Похоже, вы оба ответили в одну и ту же минуту. Тиан должен был бы довольно быстро увидеть ваши ссылки и вставить их.
 09 янв. 2017 г., 21:14
Это зарезервированные коды выхода, в соответствии сAdvanced Bash-Scripting Guide, Это означает, что эти значенияshould therefore be avoided for user-specified exit parameters.

В первом приближении 0 - это успех, ненулевое значение - сбой, 1 - общий сбой, а все, что больше, - конкретный сбой. Помимо тривиальных исключений false и test, которые оба предназначены, чтобы дать 1 за успех, есть несколько других исключений, которые я обнаружил.

Более реалистично, 0 означает успех или, возможно, сбой, 1 означает общий отказ или, может быть, успех, 2 означает общий отказ, если 1 и 0 оба используются для успеха, но, возможно, также и успех.

Команда diff дает 0, если сравниваемые файлы идентичны, 1, если они различаются, и 2, если двоичные файлы различны. 2 также означает неудачу. Команда less выдает 1 за неудачу, если только вы не предоставите аргумент, в этом случае она выходит из 0, несмотря на неудачу.

Команда more и команда spell дают 1 для сбоя, если только сбой не является результатом отказа в доступе, несуществующего файла или попытки прочитать каталог. В любом из этих случаев они выходят из 0, несмотря на неудачу.

Затем команда expr выдает 1 для sucess, если только вывод не является пустой строкой или нулем, в этом случае 0 является sucess. 2 и 3 провал.

Тогда есть случаи, когда успех или неудача неоднозначны. Когда grep не удается найти шаблон, он выходит из 1, но выходит из 2 для подлинного сбоя (например, отказано в разрешении). Klist также выходит из 1, когда он не может найти билет, хотя это на самом деле не больше, чем сбой, чем когда grep не находит шаблон или когда вы пустой каталог.

Таким образом, к сожалению, возможности Unix, которые, по-видимому, не обеспечивают какой-либо логический набор правил, даже для очень часто используемых исполняемых файлов.

 30 авг. 2016 г., 12:25
Я тоже собирался указать на поведение diff. У wget также есть подробные ошибки (например, 6 для ошибки аутентификации), но тогда они используют 1 = общая ошибка, 2..n = конкретная ошибка
Part 1: Advanced Bash Scripting Guide

Как всегда,Расширенное руководство по написанию сценариев Bash имеетотличная информация: (This was linked in another answer, but to a non-canonical URL.)

1: Catchall for general errors
2: Misuse of shell builtins (according to Bash documentation)
126: Command invoked cannot execute
127: "command not found"
128: Invalid argument to exit
128+n: Fatal error signal "n"
255: Exit status out of range (exit takes only integer args in the range 0 - 255)

Part 2: sysexits.h

Ссылки ABSGsysexits.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 */
 29 июл. 2013 г., 11:38
На BSD имеется справочная страница, обобщающая информацию из sysexits.h:man sysexits
 25 окт. 2012 г., 19:06
Обратите внимание, что в некоторых разновидностях Unix некоторые команды используют состояние выхода 2, чтобы указать другие вещи. Например, многие реализации grep используют состояние выхода 2, чтобы указать ошибку, и используют состояние выхода 1, чтобы указать, что выбранные строки не были найдены.
 08 мая 2017 г., 11:16
Что сказал @NamshubWriter.Exit status 2 является универсальным средством для некорректного использования командной строки в утилитах Unix, а не только в «некоторых вариантах Unix»; а вообще. Заголовок, показанный в этом ответе, не отражает фактические соглашения, сейчас или когда он был написан в 1987 году.

Стандартные коды выхода Unix определяются sysexits.h, как упоминалось в другом постере. Такие же коды выхода используются переносимыми библиотеками, такими как Poco - вот их список:

http://pocoproject.org/docs/Poco.Util.Application.html#16218

Сигнал 11 является сигналом SIGSEGV (нарушение сегмента), который отличается от кода возврата. Этот сигнал генерируется ядром в ответ на неправильный доступ к странице, что приводит к завершению программы. Список сигналов можно найти на странице справки по сигналам (запустите «сигнал человека»).

Стандартных кодов выхода нет, кроме 0, означающего успех. Ненулевое значение также не обязательно означает неудачу.

stdlib.h определяетEXIT_FAILURE как 1 иEXIT_SUCCESS как 0, но это об этом.

11 на segfault интересен, так как 11 - это номер сигнала, который ядро использует для уничтожения процесса в случае segfault. Вероятно, существует какой-то механизм, либо в ядре, либо в оболочке, который преобразует его в код выхода.

 10 окт. 2016 г., 10:44
Это должен быть принятый ответ.

sysexits.h есть список стандартных кодов выхода. Похоже, он датируется как минимум 1993 годом, и некоторые крупные проекты, такие как Postfix, используют его, так что я думаю, что это путь.

Со страницы руководства OpenBSD:

According to style(9), it is not good practice to call exit(3) with arbi- trary values to indicate a failure condition when ending a program. In- stead, the pre-defined exit codes from sysexits should be used, so the caller of the process can get a rough estimation about the failure class without looking up the source code.
Решение Вопроса

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" */
}

Как вы определяете статус выхода? Традиционно оболочка хранит только 8-битный код возврата, но устанавливает старший бит, если процесс был ненормально завершен.

$ sh -c 'exit 42'; echo $?
42
$ sh -c 'kill -SEGV $$'; echo $?
Segmentation fault
139
$ expr 139 - 128
11

Если вы видите что-то другое, то, вероятно, программа имеетSIGSEGV обработчик сигнала, который затем вызываетexit обычно, так что сигнал фактически не убивает. (Программы могут выбрать обработку любых сигналов, кромеSIGKILL а такжеSIGSTOP.)

 09 дек. 2013 г., 23:49
Учитывая то, как теперь возникает вопрос, это не самый полезный (и, следовательно, принятый) ответ.

Программы возвращают 16-битный код выхода. Если программа была уничтожена сигналом, то старший байт содержит используемый сигнал, в противном случае младший байт - это состояние выхода, возвращаемое программистом.

Как этот код выхода назначается переменной состояния $? затем до оболочки. Bash сохраняет младшие 7 бит состояния и затем использует 128 + (сигнал nr) для индикации сигнала.

Единственный «стандартный» Соглашение для программ: 0 для успеха, ненулевое значение для ошибки. Другое используемое соглашение - возвращать errno в случае ошибки.

Когда Linux возвращает 0, это означает успех. Все остальное означает сбой, каждая программа имеет свои коды выхода, поэтому было бы довольно долго перечислять их все ...!

Что касается кода ошибки 11, то это действительно номер ошибки сегментации, в основном это означает, что программа получила доступ к области памяти, которая не была назначена.

 09 июл. 2009 г., 08:04
Это всегда 11, потому что ядро убивает его и присваивает «выходное значение». Аналогично, другие типы неисправностей всегда будут иметь одинаковое значение выхода.

Ваш ответ на вопрос