Me topé con este problema el otro día (donde command es algo que genera una salida considerablemente larga):
...
command | sort -r -t_ -k 3.1,3.10 | head -n 1
...
sort: write failed: standard output: Broken pipe
sort: write error
Este tipo de cosas deconcierta siempre. Uno piensa primero que es un error y uno se lo achaca al programa que lo reporta. Sin embargo, hay que tener presente siempre que:
- ¿Realmente es un error o un resultado esperado y controlado?
- ¿Realmente es un problema del comando o utilería que lo reporta?
En mi caso, resultaba desconcertante porque esto se encontraba dentro de un ciclo (for) donde funcionaba bien para algunos casos. Aunque al hacer pruebas en la línea de comandos pude reproducir el problema.
Ahora bien, aunque sort es quien reporta el problema no es así quien lo causa. Aquí de hecho el problema es causado por head. La explicación de lo que ocurría fue que para algunos casos, sort (BASH o el sistema operativo) hacía una pausa para comunicar resultados, estos los toma head (a quien se le ha indicado sólo tomar el primero de ellos) quien cerraba el entubamiento por dar por concluida su labor y es entonces donde sort «tronaba».
Al entender esto, podemos ver que una posible solución es substituir head por un script en AWK o por tail (quitando la opción -r en sort, of course) pero debemos recordar que no debe terminarse el trabajo (flujo en el pipeline) antes de tiempo (debemos dar a sort oportunidad de terminar lo suyo). Esto lo menciono porque (y fue una de las razones de usar head) podemos considerar que sólo nos interesa un único resultado y no tiene caso gastar tiempo procesando todo el flujo de datos si no lo vamos a usar, pero no opodemos evitarlo si queremos tener un script o comando sin códigos o mensajes de errores.
Dr. Edu 