Me he tropezado con este problema, así que me pregunto cómo es esto posible.
Ejecución estándar de comando:
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14
info from server: "Processed 0 Failed 1 Total 1 Seconds spent 0.000017"
sent: 1; skipped: 0; total: 1
OK, intentemos obtener la primera línea solamente:
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | head -1
sent: 1; skipped: 0; total: 1
¿Qué pasa con la cabeza estándar?
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | head
sent: 1; skipped: 0; total: 1
Grep inversa? sed? ¿¡¡¿¡¿¡¿tee?!?!?!!?
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | grep -v pero
sent: 1; skipped: 0; total: 1
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | sed 's/foo/bar/'
sent: 1; skipped: 0; total: 1
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | tee
sent: 1; skipped: 0; total: 1
stderr a stdout?
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 2>&1 | tee
sent: 1; skipped: 0; total: 1
Estoy realmente perplejo ...
tee
? ¿Qué pasa si correszabix_sender <options> 2>&1 | head -1
?Respuestas:
Esto puede suceder si la aplicación escribe directamente en el TTY en lugar de STDOUT o STDERR.
Puedes jugar con este comportamiento comparando los 2 ejemplos a continuación
Observe que el primero no muestra nada, pero el segundo sí. Eso es porque enviamos la salida directamente al tty y pasamos por alto la redirección
/dev/null
.Puede sortear cosas como esta usando
script
Básicamente, la
script
utilidad crea un tty falso y ejecuta el comando en ese tty. Cualquier salida del comando se envía a STDOUT, que luego puede redirigir normalmente.fuente
script: illegal option -- c
:( ¿Hay alguna otra solución que conozcas?