Il tubo rotto non termina più i programmi?

Question

Quando installi due processi e uccidi quello in " output " del tubo, il primo processo utilizzato per ricevere il "tubo rotto" segnale, che di solito lo terminava pure. Per esempio. esecuzione

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

e quindi uscire da less usato per tornare immediatamente a una shell reattiva, su un SuSE8 o versioni precedenti. quando lo sto provando oggi, do_something_intensive è ovviamente ancora in esecuzione finché non lo uccido manualmente. Sembra che sia cambiato qualcosa (glib? Shell?) Che fa ignorare il programma "pipe spezzate" ...

Qualcuno di voi ha suggerimenti su questo? come ripristinare il precedente comportamento? perché è stato modificato (o perché è sempre esistita più semantiche)?

modifica : ulteriori test (usando lo strace) rivelano che "SIGPIPE" Viene generato , ma il programma non viene interrotto. Un semplice

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

andrà avanti con un infinito

<*>

quando meno viene ucciso. Potrei sicuramente programmare un gestore di segnale nel mio programma e assicurarmi che termini, ma sto cercando più una variabile d'ambiente o un'opzione shell che costringerebbe i programmi a terminare su SIGPIPE

modifica di nuovo : sembra essere un problema specifico di tcsh (bash lo gestisce correttamente) e dipendente dal terminale (Eterm 0.9.4)

Answer 1

Grazie per i tuoi consigli, la soluzione si sta avvicinando ...

Secondo la manpage di tcsh, le shell non di accesso ereditano il comportamento di chiusura dai loro genitori. Altri segnali hanno i valori che la shell ha ereditato dal suo genitore. & Quot;

Il che suggerisce che il mio terminale sia in realtà la radice del problema ... se ha ignorato SIGPIPE, anche la shell ignorerà SIGPIPE ...

modifica: ho la conferma definitiva che il problema si presenta solo con Eterm + tcsh e ho trovato un segnale sospettosamente mancante (SIGPIPE, SIG_DFL) nel codice sorgente di Eterm. Penso che chiuda il caso.

Answer 2

Bene, se c'è un tentativo di scrivere su una pipe dopo che il lettore è andato via, viene generato un segnale SIGPIPE. L'applicazione ha la capacità di catturare questo segnale, ma in caso contrario, il processo viene interrotto.

SIGPIPE non verrà generato fino a quando il processo di chiamata non tenta di scrivere, quindi se non c'è più output, non verrà generato.

Answer 3

Ha " fatto qualcosa di intensivo " cambiato affatto?

Come Daniel ha menzionato SIGPIPE non è una magia "la tua pipa è andata via" segnale ma piuttosto un "bel tentativo, non puoi più leggere / scrivere quella pipe" segnale.

Se hai il controllo di " fai qualcosa di intensivo " puoi cambiarlo per scrivere alcuni "indicatori di progresso" uscita mentre gira. Ciò aumenterebbe tempestivamente SIGPIPE.