La plupart des Shell récents, Bash inclus, ont une fonction intégrée kill. Dans Bash, à la fois les noms de signaux et leur numéro sont acceptés en tant qu'option, et les arguments peuvent être des identifiants de travaux ou de processus. Un statut d'exécution peut être renvoyé avec l'option -l : zéro si au moins un signal a été envoyé correctement, différent de zéro si une erreur s'est produite.

Avec la commande kill de /usr/bin, votre système peut activer des options supplémentaires, telles que la capacité de tuer des processus provenant d'autres identifiants utilisateurs que le votre, et celle de spécifier les processus par leur nom, comme avec pgrep et pkill.

Les 2 commandes kill envoient le signal TERM si aucun n'est donné.

Voici une liste des principaux signaux:

Pour tuer un processus ou une série de processus, il est de bon sens de commencer par essayer avec le signal le moins dangereux, SIGTERM. De cette façon, les programmes qui se soucient d'un arrêt correct ont une chance de suivre les procédures qui leur ont été demandé d'exécuter à la réception du signal SIGTERM, tel que purger et fermer les fichiers ouverts. Si vous envoyez un SIGKILL à un processus, vous retirez toute chance au processus d'effectuer un arrêt soigné, ce qui peut avoir des conséquences néfastes.

Mais si l'arrêt soigné ne fonctionne pas, le signal INT ou KILL peut être le seul moyen. Par exemple,quand un processus ne meurt pas avec Ctrl+C, c'est mieux d'utiliser kill -9 sur cet ID de processus:

maud: ~> ps -ef | grep stuck_process
maud    5607   2214  0 20:05 pts/5    00:00:02 stuck_process

maud: ~> kill -9 5607

maud: ~> ps -ef | grep stuck_process
maud    5614    2214 0 20:15 pts/5    00:00:00 grep stuck_process
[1]+ Killed		stuck_process

Quand un processus démarre plusieurs instances, killall peut être plus facile. Elle prend la même option que la commande kill, mais s'applique à toutes les instances d'un processus donné. Tester cette commande avant de l'employer dans un environnement de production, parce qu'elle pourrait ne pas fonctionner comme attendu sur certains UNIX commerciaux.

Il peut y avoir des situations ou vous ne souhaitez pas que les usagers de vos scripts quitte abruptement par une séquence de touches du clavier, par exemple parce que une entrée est en attente ou une purge est à faire. L'instruction trap trappe ces séquences et peut être programmée pour exécuter une liste de commandes à la récupération de ces signaux.

La syntaxe de l'instruction trap est directe:

Ceci indique à la commande trap de récupérer les SIGNAUX listés, qui peuvent être des noms de signaux avec ou sans le préfixe SIG, ou des numéros de signaux. Si un signal est 0 ou EXIT, les COMMANDES sont exécutées quand le Shell se finit. Si l'un des signaux est DEBUG, la liste des COMMANDES est exécutée après chaque commande simple. Un signal peut être aussi spécifié pour ERR; dans ce cas COMMANDES sont exécutées chaque fois qu'une commande simple s'achève avec un statut différent de zéro. Notez que ces commandes ne seront pas exécutées quand le statut d'exécution différent de zéro vient d'une instruction if, ou d'une boucle while ou until. Aucune ne sera exécutée si un AND (&&) ou un OR (||) logique donne un statut d'exécution différent de zéro, ou quand le code retour d'une commande est inversé par l'opérateur !.

Le statut renvoyé par la commande trap elle-même est zéro à moins qu'un signal invalide ait été spécifié. La commande trap admet des options qui sont documentées dans les pages info de Bash.

Voici un exemple très simple, récupérant Ctrl+C frappé par l'usager, ce qui déclenche l'affichage d'un message. Quand vous essayez de tuer ce programme sans spécifier le signal KILL, rien ne se produit:

#!/bin/bash
# traptest.sh

trap "echo Booh!" SIGINT SIGTERM
echo "pid is $$"

while :			# Ceci est équivalent à  "while true".
do
        sleep 60	# Ce script ne fait pas vraiment quelque chose.
done

Quand Bash reçoit un signal pour lequel un piège a été défini durant l'exécution d'une commande, le piège ne sera mis en oeuvre que une fois que la commande aura terminé. Quand Bash attend après une commande asynchrone via l'intégrée wait, la réception d'un signal pour lequel un piège a été défini fera que l'intégrée wait redonnera la main immédiatement avec un statut d'exécution supérieur à 128, immédiatement après quoi le piège est exécuté.