Pregunta:
Aquí hay algunas opciones en las que pensé, no estoy seguro de cuál es la correcta.
- Hubo un error de E / S en la lectura de la tubería.
- El proceso de escritura en el otro extremo de la tubería murió con una falla.
- Todos los procesos que pudieron escribir en la tubería la han cerrado.
- El búfer de escritura de la tubería está lleno.
- El par ha cerrado la otra dirección de la tubería dúplex.
- La escritura falló porque no hay procesos que puedan leer desde la tubería.
- Una llamada al sistema devolvió el error EPIPE y no se instaló ningún controlador de errores.
Respuesta:
Un proceso recibe un SIGPIPE cuando intenta escribir en una tubería (con nombre o no) o conector 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 desea que find siga ejecutándose una vez que head haya terminado (y luego haya cerrado el único descriptor de archivo abierto para lectura en esa tubería).
El comando yes 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 (el subshell), luego 2 (subshell + sleep), luego 1 (subshell) luego 0 fd leyendo de la tubería después de que el subshell cierre explícitamente su stdin, y ahí es cuando yes recibirá un SIGPIPE.
Arriba, la mayoría de los shells usan una pipe(2) mientras que ksh93 usa un socketpair(2) , pero el comportamiento es el mismo en ese sentido.
Cuando un proceso ignora el SIGPIPE, la llamada al sistema de escritura (generalmente write , pero podría ser pwrite , send , splice …) regresa con un error EPIPE . Por lo tanto, los procesos que desean manejar la tubería rota manualmente generalmente ignorarían SIGPIPE y tomarían medidas ante un error de EPIPE.