Um processo recebe um SIGPIPE quando tenta gravar em um canal (nomeado ou não) ou soquete do tipo SOCK_STREAM que não possui nenhum leitor restante.
Geralmente é um comportamento desejado. Um exemplo típico é:
find . | head -n 1
Você não deseja find
continuar executando uma vez head
finalizado (e depois fechou o único descritor de arquivo aberto para leitura nesse canal).
O yes
comando normalmente depende desse sinal para terminar.
yes | some-command
Irá escrever "y" até que algum comando termine.
Observe que não é apenas quando os comandos saem, é quando todos os leitores fecham suas leituras fd no canal. Em:
yes | ( sleep 1; exec <&-; ps -fC yes)
1 2 1 0
Haverá 1 (o subshell), depois 2 (subshell + sleep), depois 1 (subshell) e 0 leitura fd do canal após o subshell explicitamente fechar seu stdin, e é nesse momento yes
que receberá um SIGPIPE.
Acima, a maioria das conchas usa um pipe(2)
tempo ksh93
usa a socketpair(2)
, mas o comportamento é o mesmo nesse sentido.
Quando um processo ignora a SIGPIPE, a chamada sistema de escrita (em geral write
, mas poderia ser pwrite
, send
, splice
...) retorna com um EPIPE
erro. Portanto, os processos que desejam manipular o tubo quebrado manualmente geralmente ignoram o SIGPIPE e agem com um erro do EPIPE.