Pourquoi 0 est vrai, mais faux est de 1 dans le shell?

C'est une convention, mais particulièrement utile lorsque vous pensez à ce sujet. En général, si un programme réussit, c'est tout ce que vous devez savoir. Si elle échoue, cependant, vous pourriez avoir besoin de savoir toutes sortes d'informations à propos de la panne - pourquoi c'est arrivé, comment le réparer, etc. Avoir de moyenne nulle, la "réussite" et non nul synonyme d'échec vous permet de vérifier assez facilement pour la réussite, et d'enquêter sur l'erreur pour plus de détails si vous le souhaitez. Beaucoup d'Api et de cadres ont une convention similaire - fonctions qui réussissent return 0 et et ceux qui échouent à donner en retour un code d'erreur décrivant le particulier en cas d'échec.

Il y a deux problèmes ici.

Tout d'abord, l'OP question, Pourquoi 0 est vrai, mais faux est de 1 dans le shell? et la deuxième, pourquoi ne demandes de retour à 0 pour la réussite et non nulle pour défaut?

Pour répondre à l'OP de la question, nous avons besoin de comprendre à la seconde question. Les nombreuses réponses à ce post ont indiqué que c'est une convention et ont énuméré certaines des subtilités de cette convention offre. Certains de ces subtilités sont résumées ci-dessous.

Pourquoi ne demandes de retour à 0 pour la réussite et non nulle pour défaut?

Code qui appelle une opération a besoin de savoir deux choses sur le statut de sortie de l'opération. Fait l'opération de sortie avec succès? [*1] Et si l'opération n'est pas sortie avec succès pourquoi l'opération de sortie sans succès? Toute valeur peut être utilisée pour désigner succès. Mais 0 est plus pratique que n'importe quel autre nombre, car il est portable entre les plates-formes. Résumant xibo, la réponse à cette question le 16 Août 2011:

Zéro est l'encodage indépendant.

Si nous voulions stocker un(1) en un entier de 32 bits mot, la première question serait "big-endian mot ou little-endian mot?", suivi par "combien de temps sont les octets de la rédaction d'un little-endian mot?", alors que zéro sera toujours le même.

Aussi il doit s'attendre à ce que certaines personnes ont mis errno char ou court à un certain point, ou même à flotteur. (int)((char)ENOLCK) n'est pas ENOLCK lorsque le char n'est pas au moins 8 bits de long (7-bit ASCII char machines sont pris en charge par les systèmes UNIX), tandis que (int)((char)0) 0 indépendant de détails architecturaux de char.

Une fois qu'il est déterminé que la valeur 0 sera la valeur de retour pour le succès, il est logique d'utiliser une valeur non nulle en cas d'échec. Cela permet de nombreuses codes de sortie pour répondre à la question de savoir pourquoi l'opération a échoué.

Pourquoi 0 est vrai, mais faux est de 1 dans le shell?

L'un des principaux usages de l'obus est d'automatiser les processus par les scripts. Habituellement, cela signifie que l'invocation d'une opération et ensuite de faire autre chose conditionnelle basée sur le statut de sortie de l'opération. Philippe A. bien expliqué dans sa réponse à ce post que

En bash et en shells unix en général, les valeurs de retour ne sont pas de type boolean.
Ils sont des entiers codes de sortie.

Il est nécessaire ensuite d'interpréter le statut de sortie de ces opérations comme une valeur booléenne. Il fait sens pour mapper un succès (0) état de sortie de vrai et non-zéro/erreur de sortie d'état false. Ceci permet l'exécution conditionnelle de chaînée des commandes shell.

Voici un exemple mkdir deleteme && cd $_ && pwd. Parce que le shell interprète 0 conforme cette commande commodément fonctionne comme prévu. Si la coque ont été à interpréter 0 à faux, alors vous auriez à inverser le interprétée statut de sortie pour chaque opération.

En bref, il serait absurde pour le shell pour interpréter 0 à faux compte tenu de la convention que les demandes de retour de 0 pour une sortie de crise réussie d'état.

---

[*1]: Oui, de nombreuses fois les opérations besoin de retourner plus qu'un simple message de succès mais qui est au-delà de la portée de ce fil.

Voir aussi L'Annexe E dans l'Advanced Bash Scripting Guide

Un point fondamental, je trouve important de comprendre cela. En bash et en shells unix en général, les valeurs de retour ne sont pas de type boolean. Ils sont des entiers codes de sortie. En tant que tel, vous devez les évaluer en fonction de la convention en disant: 0 synonyme de réussite, et d'autres valeurs à une certaine erreur.

Avec test, [ ] ou [[ ]] opérateurs, bash conditions évaluent aussi vrai dans le cas d'un code de sortie 0 (le résultat de /bin/true). Sinon, ils évaluent comme faux.

Chaînes sont évalués différemment des codes de sortie:

if [ 0 ] ; then echo not null ; fi
if [ $(echo 0) ] ; then echo not null ; fi

if [ -z "" ] ; then echo null ; fi

La (( )) opérateur arithmétique interprète 1 et 0 comme le vrai et le faux. Mais que l'opérateur ne peut être utilisé comme un remplacement complet pour test, [ ] ou [[ ]]. Voici un exemple montrant lorsque l'opérateur arithmétique est utile:

for (( counter = 0 ; counter < 10 ; counter ++ )) ; do
  if (( counter % 2 )) ; then echo "odd number $counter" ; fi
done

Autant que je sache, cela viennent de la convention C que tu doit retourner 0 si réussi.
Voir:

man close

La plupart de la C POSIX () de l'api est l'accumulation de ce genre.
http://en.wikipedia.org/wiki/C_POSIX_library

d'une convention datant des premiers jours de Unix.

Par convention, tous les appels système renvoient 0 si réussir, des non-zéro autrement, parce que les nombres différents peuvent être utilisés pour indiquer les différentes raisons de l'échec.

Coquilles de suivre cette convention, 0 signifie que la dernière commande a réussi, non nulle sinon. De même, la non-zéro de la valeur de retour est très pratique pour la sortie des messages d'erreur: par exemple, 1: "mort cérébrale", 2: "sans cœur", et ainsi de suite.