Comment un script shell évite-t-il le Sigpipe qui serait causé par l'utilisation d'un descripteur de fichier fermé ?

Un script shell peut perdre ses descripteurs de fichier standard et autres si l'autre extrémité disparaît. Cela peut se produire en mettant fin à un ssh client utilisé pour lancer le script :

$ ssh localhost test
^C

Cela lance un bash script appelé test via SSH et un Ctrl C est utilisé pour terminer le ssh commande. Cela ne met pas fin au test qui continue de s'exécuter mais ferme les descripteurs de fichiers joints (par exemple, entrée/sortie/erreur standard).

Si test essaie d'utiliser ces descripteurs de fichiers fermés, il se terminera par un SIGPIPE . Un simple echo suffira.

Une des choses test pourrait avoir est un log fonction qui utilise echo pour écrire des messages dans le journal systemd et également dans l'erreur standard. Quelque chose comme ça :

log() {
 echo "$*" | systemd-cat -t test
 echo >&2 "$*"
}

Le deuxième echo lève un SIGPIPE après le ssh session est tuée (Ctrl C ). Cela peut être protégé contre, afin que l'exécution continue sans le echo offensant , en mettant le echo dans un sous-shell :

( echo >&2 "$*" )

Mais existe-t-il un meilleur moyen ?

Réponse acceptée :

Vous pouvez si vous le souhaitez ignorer SIGPIPE dans le script :

trap "" PIPE