Un tuyau cassé ne termine plus les programmes?

Question

Lorsque vous dirigez deux processus et que vous supprimez celui qui se trouve à la "sortie" du tuyau, le premier processus utilisé pour recevoir le "tuyau cassé" signal, qui le terminait généralement aussi. Par exemple. en cours d'exécution

#include <stdio.h>
int main() 
{
   while(1) printf("dumb test\n");
   exit(0);
}
gt; do_something_intensive | less

puis en quittant less , on vous renvoie immédiatement à un shell sensible, sur une version de SuSE8 ou une version antérieure. Quand j'essaie aujourd'hui, do_something_intensive est évidemment toujours en cours d'exécution jusqu'à ce que je le tue manuellement. Il semble que quelque chose a changé (glib? Shell?) Qui oblige le programme à ignorer les "tuyaux cassés". ...

Quelqu'un parmi vous a des indices à ce sujet? comment restaurer le comportement précédent? pourquoi a-t-il été modifié (ou pourquoi a-t-il toujours existé une sémantique multiple)?

modifier : d'autres tests (en utilisant strace) révèlent que " SIGPIPE " est généré, mais que le programme n'est pas interrompu. Un simple

--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(1, "dumb test\ndumb test\ndumb test\ndu"..., 1024) = -1 EPIPE (Broken pipe)

continuera avec une infinie

<*>

lorsque moins est tué. Je pourrais bien sûr programmer un gestionnaire de signaux dans mon programme et veiller à ce qu'il se termine, mais je suis plus à la recherche d'une variable d'environnement ou d'une option de shell qui forcerait les programmes à se terminer sur SIGPIPE

modifier à nouveau : il semble s'agir d'un problème spécifique à tcsh (bash le gère correctement) et dépendant du terminal (Eterm 0.9.4)

Answer 1

Merci pour vos conseils, la solution se rapproche ...

Selon la page de manuel de tcsh, les shells "non connectés" héritent du comportement de terminaison de leurs parents. Les autres signaux ont les valeurs que le shell a héritées de son parent. "

Ce qui suggère que mon terminal est en réalité la racine du problème ... s'il ignore SIGPIPE, le shell lui-même ignorera également SIGPIPE ...

modifier: j'ai la confirmation définitive que le problème ne se pose qu'avec Eterm + tcsh et que j'ai trouvé un signal manquant de manière suspecte (SIGPIPE, SIG_DFL) dans le code source Eterm. Je pense que ça ferme l'affaire.

Answer 2

Eh bien, si vous tentez d'écrire dans un tuyau après que le lecteur soit parti, un signal SIGPIPE est généré. L’application a la capacité d’attraper ce signal, mais si ce n’est pas le cas, le processus est arrêté.

Le SIGPIPE ne sera pas généré tant que le processus appelant n'aura pas essayé d'écrire. Par conséquent, s'il n'y a plus de sortie, elle ne sera pas générée.

Answer 3

a " fait quelque chose d'intensif " changé du tout?

Comme Daniel l'a mentionné, SIGPIPE n'est pas une magie "votre pipe est partie". signal mais plutôt "un bel essai, vous ne pouvez plus lire / écrire ce tuyau" signal.

Si vous avez le contrôle de " faire quelque chose d'intensif " vous pouvez le modifier pour écrire des " indicateurs de progression " sortie comme il tourne. Cela permettrait de relever le SIGPIPE rapidement.