Wyjście komendy nie w stderr ani stdout

Natknąłem się na ten problem, więc zastanawiam się, jak to możliwe?

Standardowy przebieg polecenia:

# 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, spróbujmy pobrać tylko pierwszą linię:

# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | head -1
sent: 1; skipped: 0; total: 1

Co ze standardową głową?

# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | head 
sent: 1; skipped: 0; total: 1

Odwrotny grep? sed? trójnik?!?!?!!?

# 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 na stdout?

# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 2>&1 | tee
sent: 1; skipped: 0; total: 1

Jestem naprawdę zdziwiony ...

Może się to zdarzyć, jeśli aplikacja pisze bezpośrednio do TTY zamiast STDOUT lub STDERR.

Możesz grać z tym zachowaniem, porównując 2 poniższe przykłady

( echo foo ) &>/dev/null
( echo foo > $(tty) ) &>/dev/null

Zauważ, że pierwszy nic nie pokazuje, ale drugi tak. Jest tak, ponieważ wysłaliśmy dane wyjściowe bezpośrednio do tty i pominęliśmy przekierowanie do /dev/null.

Możesz obejść takie rzeczy za pomocą script

script -c '( echo foo > $(tty) ) &>/dev/null'  >/dev/null

Zasadniczo scriptnarzędzie tworzy fałszywy tty i uruchamia polecenie w tym tty. Wszelkie dane wyjściowe polecenia są wysyłane do STDOUT, które można następnie przekierować jak zwykle.