Il existe plusieurs façons d'aborder ce problème. En supposant que l'une de vos exigences est d'exécuter un script / une fonction shell contenant quelques commandes shell et de vérifier si le script s'est exécuté avec succès et de générer des erreurs en cas d'échec.
Les commandes shell reposent généralement sur des codes de sortie renvoyés pour indiquer au shell si l'opération a réussi ou échoué en raison d'événements inattendus.
Donc, ce que vous voulez faire relève de ces deux catégories
- sortie en cas d'erreur
- quitter et nettoyer en cas d'erreur
Selon celui que vous souhaitez faire, il existe des options de shell disponibles à utiliser. Pour le premier cas, le shell fournit une option avec set -eet pour le second, vous pouvez faire un trapsurEXIT
Dois-je utiliser exitdans mon script / ma fonction?
L'utilisation exitaméliore généralement la lisibilité Dans certaines routines, une fois que vous connaissez la réponse, vous souhaitez quitter immédiatement la routine d'appel. Si la routine est définie de manière à ne pas nécessiter de nettoyage supplémentaire une fois qu'elle détecte une erreur, ne pas quitter immédiatement signifie que vous devez écrire plus de code.
Donc, dans les cas où vous devez effectuer des actions de nettoyage sur le script pour rendre la fin du script propre, il est préférable de ne pas utiliser exit.
Dois-je utiliser set -epour une erreur à la sortie?
Non!
set -eétait une tentative pour ajouter une "détection automatique d'erreur" au shell. Son objectif était de provoquer l'abandon du shell à chaque fois qu'une erreur se produisait, mais cela comporte de nombreux pièges potentiels, par exemple,
Les commandes qui font partie d'un test if sont immunisées. Dans l'exemple, si vous vous attendez à ce qu'il se casse lors de la testvérification du répertoire non existant, ce ne serait pas le cas, il passe à la condition else
set -e
f() { test -d nosuchdir && echo no dir; }
f
echo survived
Les commandes dans un pipeline autre que le dernier sont immunisées. Dans l'exemple ci-dessous, parce que le code de sortie de la commande la plus récemment exécutée (le plus à droite) est considéré ( cat) et qu'il a réussi. Cela pourrait être évité en définissant l' set -o pipefailoption, mais c'est toujours une mise en garde.
set -e
somecommand that fails | cat -
echo survived
Utilisation recommandée - trapen sortie
Le verdict est que si vous voulez pouvoir gérer une erreur au lieu de quitter aveuglément, au lieu d'utiliser set -e, utilisez un trapsur le ERRpseudo-signal.
Le ERRpiège n'est pas d'exécuter du code lorsque le shell lui-même se termine avec un code d'erreur différent de zéro, mais lorsqu'une commande exécutée par ce shell qui ne fait pas partie d'une condition (comme si cmd, ou cmd ||) se termine avec un statut de sortie différent de zéro .
La pratique générale est de définir un gestionnaire d'interruptions pour fournir des informations de débogage supplémentaires sur quelle ligne et ce qui cause la sortie. Souvenez-vous que le code de sortie de la dernière commande à l'origine du ERRsignal serait toujours disponible à ce stade.
cleanup() {
exitcode=$?
printf 'error condition hit\n' 1>&2
printf 'exit code returned: %s\n' "$exitcode"
printf 'the command executing at the time of the error was: %s\n' "$BASH_COMMAND"
printf 'command present on line: %d' "${BASH_LINENO[0]}"
# Some more clean up code can be added here before exiting
exit $exitcode
}
et nous utilisons simplement ce gestionnaire comme ci-dessous en plus du script qui échoue
trap cleanup ERR
En rassemblant cela sur un simple script qui contenait falseà la ligne 15, les informations que vous obtiendriez comme
error condition hit
exit code returned: 1
the command executing at the time of the error was: false
command present on line: 15
Le trapfournit également des options indépendamment de l'erreur pour simplement exécuter le nettoyage à la fin du shell (par exemple, votre script shell se termine), au signal EXIT. Vous pouvez également intercepter plusieurs signaux en même temps. La liste des signaux pris en charge à intercepter se trouve sur le trap.1p - page de manuel Linux
Une autre chose à noter serait de comprendre qu'aucune des méthodes fournies ne fonctionne si vous traitez avec des sous-shells, auquel cas vous devrez peut-être ajouter votre propre gestion des erreurs.
Sur un sous-shell avec set -ene fonctionnerait pas. Le falseest limité au sous-shell et n'est jamais propagé au shell parent. Pour faire la gestion des erreurs ici, ajoutez votre propre logique à faire(false) || false
set -e
(false)
echo survived
La même chose se produit trapégalement. La logique ci-dessous ne fonctionnerait pas pour les raisons mentionnées ci-dessus.
trap 'echo error' ERR
(false)