Output of command not in stderr nor stdout

Question

I've stumbled on this issue, so I'm wondering how is this possible?

Standard run of command:

# 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, lets try to get the first line only:

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

What about standard head?

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

Inverse grep? 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 to stdout?

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

I'm really puzzled...

What were you expecting with tee? What happens if you run zabix_sender <options> 2>&1 | head -1? — terdon, Apr 02 '13 at 16:13
I wonder if it is sending to stdin. If not then where did it get a file-descriptor of the tty. — ctrl-alt-delor, Jan 15 '21 at 07:24

score 21 · Accepted Answer · answered Apr 02 '13 at 16:23

This can happen if the application is writing directly to the TTY instead of STDOUT or STDERR.

You can play with this behavior by comparing the 2 examples below

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

Notice the first doesn't show anything, but the second does. That's because we sent the output directly to the tty and bypassed the redirection to /dev/null.

You can get around stuff like this by using script

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

Basically the script utility creates a fake tty and launches the command in that tty. Any output from the command is sent to STDOUT which you can then redirect as normal.

Thank you for the pointer to "script"! That's exactly the thing I needed to work around gpg/gpg2's stubborn insistence on not reading from stdin. — Eric, Jun 09 '14 at 14:10
script: illegal option -- c :( Are there any other workarounds you know of? — Aaron, Jun 14 '19 at 22:31

Output of command not in stderr nor stdout

1 Answers1

Linked