Saída do comando não no stderr nem no stdout

Eu tropecei nessa questão, então estou me perguntando como isso é possível.

Execução de comando padrão:

# 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, vamos tentar obter apenas a primeira linha:

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

E a cabeça padrão?

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

Grep inverso? sed? camiseta?!?!? !!?

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

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

Estou realmente intrigado ...

Isso pode acontecer se o aplicativo estiver gravando diretamente no TTY, em vez de STDOUT ou STDERR.

Você pode jogar com esse comportamento comparando os 2 exemplos abaixo

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

Observe que o primeiro não mostra nada, mas o segundo mostra. Isso porque enviamos a saída diretamente para o tty e ignoramos o redirecionamento para /dev/null.

Você pode contornar coisas assim usando script

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

Basicamente, o scriptutilitário cria um tty falso e inicia o comando nesse tty. Qualquer saída do comando é enviada para STDOUT, que você pode redirecionar normalmente.