tubo quebrado não termina programas?

Question

Quando você canaliza dois processos e matar a do "output" do tubo, o primeiro processo usado para receber o sinal de "Broken Pipe", que geralmente terminada lo cabeceira. Por exemplo. correndo

$> do_something_intensive | less

e, em seguida, sair do menos usado para retornar imediatamente a um shell responsivo, em um SuSE8 ou ex-releases. quando eu estou tentando que hoje, do_something_intensive é, obviamente, ainda está em execução até que eu matá-lo manualmente. Parece que alguma coisa mudou (glib? Shell?) Que faz programa de ignorar "canos quebrados" ...

Qualquer um de vocês tem dicas sobre isso? como restaurar o comportamento anterior? por isso que foi alterado (ou por que sempre existiram várias semântica)?

editar : mais testes (utilizando strace) revelam que "SIGPIPE" é gerado, mas que o programa não é interrompido. Um simples

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

vai continuar com uma interminável

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

quando menos é morto. Eu poderia com certeza programa de um manipulador de sinal no meu programa e garantir que ele termina, mas eu estou mais procurando alguma variável de ambiente ou uma opção de shell que forçaria programas para terminar em SIGPIPE

editar novamente : parece ser um problema específico do tcsh (bash alças-lo corretamente) e do terminal-dependente (Eterm 0.9.4)

Answer 1

Obrigado por seus conselhos, a solução está se aproximando ...

De acordo com a página do manual de tcsh "cascas não de login herdar o comportamento terminar de seus pais. Outros sinais têm os valores que a shell herdados de seu pai."

que sugerem minha Terminal é realmente a raiz do problema ... se ele ignorou SIGPIPE, o próprio shell irá ignorar SIGPIPE bem ...

edit: eu tenho a confirmação definitiva de que o problema só surgem com Eterm + tcsh e encontrou um sinal suspeitosamente faltando (SIGPIPE, SIG_DFL) em código-fonte Eterm. Eu acho que perto o caso.

Answer 2

Bem, se houver uma tentativa de escrever a um tubo depois de o leitor tenha ido embora, um sinal SIGPIPE é gerada. A aplicação tem a capacidade de pegar esse sinal, mas se isso não acontecer, o processo é morto.

O SIGPIPE não será gerado até que as tentativas processo de chamada para escrever, por isso, se não há mais saída, não será gerada.

Answer 3

Tem "fazer algo intensivo" mudou em tudo?

Como Daniel mencionou SIGPIPE não é uma mágica "seu tubo foi embora" sinal, mas sim uma "boa tentativa, você não pode ler / escrever que pipe" sinal.

Se você tem o controle de "fazer algo intensivo" você pode alterá-lo para escrever alguma saída "indicador de progresso", como ele gira. Isso elevaria o SIGPIPE em tempo hábil.