Conserver les codes de sortie lors de la capture de SIGINT et similaire?

Si j'utilise trapcomme décrit par exemple sur http://linuxcommand.org/wss0160.php#trap pour attraper ctrl-c (ou similaire) et nettoyer avant de quitter, je change le code de sortie retourné.

Maintenant, cela ne fera probablement pas de différence dans le monde réel (par exemple parce que les codes de sortie ne sont pas portables et en plus de cela pas toujours sans ambiguïté comme discuté dans Code de sortie par défaut lorsque le processus est terminé? ) Mais je me demande toujours s'il y a vraiment aucun moyen d'empêcher cela et de retourner le code d'erreur par défaut pour les scripts interrompus à la place?

Exemple (en bash, mais ma question ne doit pas être considérée comme spécifique à bash):

#!/bin/bash
trap 'echo EXIT;' EXIT
read -p 'If you ctrl-c me now my return code will be the default for SIGTERM. ' _
trap 'echo SIGINT; exit 1;' INT
read -p 'If you ctrl-c me now my return code will be 1. ' _

Production:

$ ./test.sh # doing ctrl-c for 1st read
If you ctrl-c me now my return code will be the default for SIGTERM.
$ echo $?
130
$ ./test.sh # doing ctrl-c for 2nd read
If you ctrl-c me now my return code will be the default for SIGTERM.
If you ctrl-c me now my return code will be 1. SIGINT 
EXIT
$ echo $?
1

(Modifié pour le supprimer afin de le rendre plus conforme à POSIX.)

(Modifié à nouveau pour en faire un script bash à la place, ma question n'est pas spécifique au shell.)

Édité pour utiliser le "INT" portable pour le piège en faveur du "SIGINT" non portable.

Modifié pour supprimer les accolades inutiles et ajouter une solution potentielle.

Mettre à jour:

Je l'ai résolu maintenant en quittant simplement avec certains codes d'erreur codés en dur et en piégeant EXIT. Cela peut être problématique sur certains systèmes car le code d'erreur peut différer ou le piège EXIT n'est pas possible, mais dans mon cas, c'est assez bien.

trap cleanup EXIT
trap 'exit 129' HUP
trap 'exit 130' INT
trap 'exit 143' TERM

Tout ce que vous devez faire est de changer le gestionnaire EXIT dans votre gestionnaire de nettoyage. Voici un exemple:

#!/bin/bash
cleanup() {
    echo trapped exit
    trap 'exit 0' EXIT
}
trap cleanup EXIT
read -p 'If you ctrl-c me now my return code will be the default for SIGTERM. '

En fait, l'interruption de l'interne de bash readsemble être un peu différente de l'interruption d'une commande exécutée par bash. Normalement, lorsque vous entrez trap, $?est défini et vous pouvez le conserver et quitter avec la même valeur:

trap 'rc=$?; echo $rc SIGINT; exit $rc' INT
trap 'rc=$?; echo $rc EXIT; exit $rc' EXIT

Si votre script est interrompu lors de l'exécution d'une commande comme sleep ou même d'une commande intégrée wait, vous verrez

130 SIGINT
130 EXIT

et le code de sortie est 130. Cependant, pour read -p, il semble $?être 0 (de toute façon sur ma version de bash 4.3.42).

Le traitement des signaux pendant readpourrait être en cours, selon le fichier des changements dans ma version ... (/ usr / share / doc / bash / CHANGES)

les changements entre cette version, bash-4.3-alpha, et la version précédente, bash-4.2-release.

3. Nouvelles fonctionnalités de Bash

   r. En mode Posix, la «lecture» est interruptible par un signal piégé. Après avoir exécuté le gestionnaire d'interruptions, la lecture renvoie un signal 128 + et supprime toute entrée partiellement lue.

Tout code de sortie de signal habituel sera disponible lors $?de l'entrée dans le gestionnaire de déroutement:

sig_handler() {
    exit_status=$?  # Eg 130 for SIGINT, 128 + (2 == SIGINT)
    echo "Doing signal-specific up"
    exit "$exit_status"
}
trap sig_handler INT HUP TERM QUIT

S'il existe une interruption EXIT distincte, vous pouvez utiliser la même méthodologie: conserver immédiatement le statut de sortie transmis par le gestionnaire de signaux (s'il y en a un), puis renvoyer le statut de sortie enregistré.

Il suffit de renvoyer un code d'erreur ne suffit pas pour simuler une sortie par SIGINT. Je suis surpris que personne n'ait mentionné cela jusqu'à présent. Pour en savoir plus: https://www.cons.org/cracauer/sigint.html

La bonne façon est:

for sig in EXIT ABRT HUP INT PIPE QUIT TERM; do
    trap "cleanup;
          [ $sig  = EXIT ] && normal_exit_only_cleanup;
          [ $sig != EXIT ] && trap - $sig EXIT && kill -s $sig $$
         " $sig
done

Cela fonctionne avec Bash, Dash et zsh. Pour plus de portabilité, vous devez utiliser des spécifications de signal numérique (d'un autre côté, zsh attend un paramètre de chaîne pour la killcommande ...)

Notez également le traitement spécial du EXITsignal. Cela est dû au fait que certains shells (à savoir Bash) exécutent également des interruptions EXITpour tout signal (après des interruptions éventuellement définies sur ce signal). La réinitialisation du EXITpiège empêche cela.

Exécution de code uniquement à la sortie "normale"

La vérification [ $sig = EXIT ]permet d'exécuter du code uniquement à la sortie normale (non signalée). Cependant, tous les signaux doivent avoir des pièges qui réinitialisent enfin le piège EXIT; normal_exit_only_cleanupsera également appelé pour les signaux qui ne le font pas. Il sera également exécuté par une sortie via set -e. Cela peut être résolu en interceptant ERR(qui n'est pas pris en charge par Dash) et en ajoutant une vérification [ $sig = ERR ]avant le kill.

Version simplifiée Bash uniquement

D'un autre côté, ce comportement signifie que dans Bash, vous pouvez simplement faire

trap cleanup EXIT

pour simplement exécuter du code de nettoyage et conserver l'état de sortie.

édité

• Élaborer le comportement de Bash de "EXIT piège tout"

• Supprimer le signal KILL, qui ne peut pas être piégé

• Supprimer les préfixes SIG des noms de signaux

• N'essayez pas de kill -s EXIT

• Prendre set -een compte / ERR