Estou tentando entender melhor o SIGPIPE no Linux.
Eu executei este experimento: { ls -al /tmp/ ; echo "$?" 1>&2 ; } | head
e ele ecoa 141o que eu entendo ser um código de saída fornecido para processos que saem com SIGPIPE Anteriormente, eu fazia muito isso sem entender as nuances SIGPIPEe geralmente executo set -eEuo pipefailisso, estava tentando entender por que meu o código não falhava o tempo todo devido a canos quebrados... Então fiz esse outro experimento: ( set -o pipefail; { ls -al /tmp/ ; echo "$?" 1>&2 ; } | head; )e obtive um 0 no eco daquela vez... então, quando pipefailestá ativado, isso significa que SIGPIPEestá suprimido? ou estou entendendo mal o que está acontecendo aqui?
Responder1
lspode conseguir gravar toda a sua saída antes de headsair e quebrar o canal, mesmo que a saída lsseja maior do que a headimpressa. Isto é porque:
headpode ler mais do que eventualmente imprimir,- e há um buffer para o tubo de qualquer maneira.
SIGPIPE é acionado pela gravação real em um canal quebrado. Se lsconseguir escrever toda a sua saída antes de headsair, não haverá nenhum ato de escrita que acione o SIGPIPE.
Ou lspode não conseguir gravar toda a sua saída antes de headsair. Então ele tentará escrever mais e obterá o SIGPIPE.
Como lse headrodando em paralelo, acho que em geral existe uma condição de corrida. Pode acontecer que alguma saída específica do lsSIGPIPE acione ou não, aleatoriamente.
Tente com yesem vez de ls …:
{ yes ; echo "$?" 1>&2 ; } | head
ou
( set -o pipefail; { yes ; echo "$?" 1>&2 ; } | head; )
yesgera uma saída que não termina sozinha, portanto após headas saídas sempre haverá um ato de escrita que aciona o SIGPIPE. Cada um dos comandos acima lhe dará 141certeza.
Isto não tem nada a ver com pipefail.