Pourquoi l'utilisation de «oui» sur les pipelines bash * ne * cause-t-elle pas des boucles infinies?

Selon sa documentation, bash attend que toutes les commandes d'un pipeline aient fini de s'exécuter avant de continuer

Le shell attend que toutes les commandes du pipeline se terminent avant de renvoyer une valeur.

Alors pourquoi la commande se yes | truetermine-t-elle immédiatement? La yesboucle ne devrait-elle pas indéfiniment et empêcher le pipeline de revenir?

Et une sous-question: selon la spécification POSIX , les pipelines shell peuvent choisir de retourner après la fin de la dernière commande ou d'attendre que toutes les commandes se terminent. Les coquilles communes ont-elles un comportement différent dans ce sens? Y a-t-il des obus yes | truequi boucleront pour toujours?

À la truesortie, le côté lecture du tuyau est fermé, mais yescontinue d'essayer d'écrire sur le côté écriture. Cette condition est appelée "pipe cassée", et elle amène le noyau à envoyer un SIGPIPEsignal à yes. Puisque yesne fait rien de spécial sur ce signal, il sera tué. S'il ignorait le signal, son writeappel échouerait avec un code d'erreur EPIPE. Les programmes qui font cela doivent être prêts à remarquer EPIPEet à arrêter d'écrire, sinon ils entreront dans une boucle infinie.

Si vous faites strace yes | true^1, vous pouvez voir le noyau se préparer pour les deux possibilités:

write(1, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"..., 4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=17556, si_uid=1000} ---
+++ killed by SIGPIPE +++

stracesurveille les événements via l'API de débogage, qui lui indique d'abord le retour de l'appel système avec une erreur, puis le signal. Du yespoint de vue, cependant, le signal arrive en premier. (Techniquement, le signal est délivré après que le noyau retourne le contrôle dans l'espace utilisateur, mais avant que d'autres instructions machine ne soient exécutées, donc la fonction write"wrapper" de la bibliothèque C n'a pas la possibilité de définir errnoet de revenir à l'application.)

¹ Malheureusement, il straceest spécifique à Linux. La plupart des Unix modernes ont une commande qui fait quelque chose de similaire, mais elle a souvent un nom différent, elle ne décode probablement pas les arguments syscall aussi complètement, et parfois elle ne fonctionne que pour root.

Y a-t-il des coquilles où oui | vrai va boucler pour toujours?

Peu probable, car la yescommande utilise le tuyau, et il échouera lorsque le tuyau sera cassé. sleepd'autre part, n'utilise pas le tuyau, donc:

sleep 100000000 | true

fonctionnera pendant 100000000 secondes, au moins.