Un proceso recibe un SIGPIPE cuando intenta escribir en una tubería (con nombre o no) o en un socket de tipo SOCK_STREAM que no tiene ningún lector.
Generalmente es un comportamiento deseado. Un ejemplo típico es:
find . | head -n 1
No querrá find
seguir ejecutándose una vez que head
haya finalizado (y luego haya cerrado el único descriptor de archivo abierto para leer en esa tubería).
El yes
comando generalmente se basa en esa señal para terminar.
yes | some-command
Escribirá "y" hasta que termine algún comando.
Tenga en cuenta que no es solo cuando los comandos salen, es cuando todos los lectores han cerrado su lectura fd a la tubería. En:
yes | ( sleep 1; exec <&-; ps -fC yes)
1 2 1 0
Habrá 1 (la subshell), luego 2 (subshell + sleep), luego 1 (subshell) luego 0 fd lectura de la tubería después de que la subshell cierre explícitamente su stdin, y es entonces cuando yes
recibirá un SIGPIPE.
Arriba, la mayoría de los shells usan a pipe(2)
while ksh93
y a socketpair(2)
, pero el comportamiento es el mismo en ese sentido.
Cuando un proceso ignora el SIGPIPE, la llamada al sistema de escritura (por lo general write
, pero podría ser pwrite
, send
, splice
...) vuelve con un EPIPE
error. Por lo tanto, los procesos que desean manejar la tubería rota manualmente ignorarían SIGPIPE y tomarían medidas ante un error EPIPE.