Écriture de try catch finally dans un shell

Question

Est-ce qu'il existe une commande linux bash comme la commande java try catch finally ? Ou est-ce que le shell linux continue toujours ?

try {
   `executeCommandWhichCanFail`
   mv output
} catch {
    mv log
} finally {
    rm tmp
}

Answer 1

Attention : les trappes de sortie ne sont pas toujours excusé. Depuis que j'ai écrit cette réponse, j'ai rencontré des situations dans lesquelles mon piège de sortie n'était pas exécuté, ce qui entraînait la perte de fichiers, pour une raison que je n'ai pas encore trouvée.

Le problème s'est produit lorsque j'ai arrêté un script python avec Ctrl+C qui, à son tour, a exécuté un script bash script utilisant des pièges de sortie -- ce qui devrait en fait entraîner l'exécution des pièges de sortie, puisque les pièges de sortie sont exécutés sur les serveurs SIGINT en bash.

Ainsi, alors que les trap .. exit est utile pour le nettoyage, il y a toujours des scénarios où il ne sera pas exécuté, les plus évidents étant les coupures de courant et la réception d'un message d'alerte. SIGKILL .

---

Je me retrouve souvent avec des scripts bash qui deviennent assez volumineux, car j'ajoute des options supplémentaires ou je les modifie d'une autre manière. Lorsqu'un bash-scripts contient beaucoup de fonctions, l'utilisation de 'trap EXIT' peut devenir non triviale.

Par exemple, considérons un script invoqué en tant que

dotask TASK [ARG ...]

où chaque TASK peut se composer de sous-étapes, pour lesquelles il est souhaitable d'effectuer un nettoyage entre les deux.

Dans ce cas, il est utile de travailler avec des sous-coquilles pour produire des pièges de sortie, par exemple

function subTask (
    local tempFile=$(mktemp)
    trap "rm '${tempFile}'" exit
    ...
)

Cependant, travailler avec des sous-shells peut s'avérer délicat, car ils ne peuvent pas définir les variables globales du shell parent.

En outre, il est souvent peu pratique d'écrire une seule trappe de sortie. Par exemple, les étapes de nettoyage peuvent dépendre du chemin parcouru par une fonction avant de rencontrer une erreur. Il serait intéressant de pouvoir faire des déclarations de nettoyage de type RAII :

function subTask (
    ...
    onExit 'rm tmp.1'
    ...
    onExit 'rm tmp.2'
    ...
)

Il semblerait évident d'utiliser quelque chose comme

handlers=""
function onExit { handlers+="$1;"; trap "$handlers" exit; }

pour mettre à jour le piège. Mais cela échoue pour les sous-shells imbriqués, car cela entraînerait l'exécution prématurée des gestionnaires du shell parent. Le code du client devrait explicitement réinitialiser l'élément handlers au début de la sous-coquille.

Solutions discutées dans [plusieurs pièges bash pour le même signal]. qui corrige le piège en utilisant la sortie de trap -p EXIT échouera également : Même si les subshells n'héritent pas de la fonction EXIT piège, trap -p exit affichera le gestionnaire de l'interpréteur de commandes parent, de sorte qu'une fois encore, une réinitialisation manuelle est nécessaire.