Le tube, et qui meurt en premier

Il se termine, et vite : $0,26$ seconde mesurée, trois lignes affichées. Les codes de sortie mesurés sont 141 pour le générateur, 0 pour head.

Le déroulement, dans l'ordre :

• Le shell lance les deux programmes en même temps et branche la sortie standard du premier sur l'entrée standard du second. Un tube n'est pas un fichier temporaire : rien n'est stocké sur disque.
• head lit trois lignes, les affiche, et ferme son entrée.
• Le générateur, qui écrit toujours, écrit maintenant dans un tube dont personne ne tient plus l'autre bout. Le système lui envoie le signal SIGPIPE, numéro $13$, dont l'effet par défaut est la mort du processus. D'où le code $141=128+13$.

Ce que ce code de sortie enseigne. Le générateur n'a pas décidé de s'arrêter : il a été arrêté. C'est le mécanisme qui rend les tubes utilisables sur des flux infinis ou immenses — ./enorme | head -3 ne lit pas le fichier entier. Un programme qui ne veut pas mourir ainsi peut ignorer SIGPIPE, mais il doit alors vérifier ce que rend chaque printf, et l'immense majorité ne le fait pas.

Le second effet, moins visible. Le tube a une capacité bornée (quelques dizaines de kilo-octets). Si le lecteur est lent, l'écrivain se bloque une fois le tube plein, et repart quand de la place se libère. Les deux programmes se régulent donc l'un l'autre, sans se connaître et sans mémoire proportionnelle aux données : c'est ce qui permet à ./generer | ./filtrer | ./compter de traiter un téraoctet dans quelques kilo-octets de mémoire.

La leçon de conception, déjà donnée dans le cours : un programme qui lit stdin et écrit stdout se compose avec tous les autres. Un programme qui ouvre lui-même "entree.txt" ne se compose avec rien — et ne bénéficie ni de l'arrêt anticipé, ni de la régulation.