14

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...

migrated from serverfault.com Apr 2 '13 at 16:07

This question came from our site for system and network administrators.

  • What were you expecting with tee? What happens if you run zabix_sender <options> 2>&1 | head -1? – terdon Apr 2 '13 at 16:13
14

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 9 '14 at 14:10
  • Thanks. Took quite a bit of searching to get here. Amazing that it's such an unpopular question (I'm dealing with VLC). – Paul Mar 8 at 17:22
  • script: illegal option -- c :( Are there any other workarounds you know of? – Aaron Jun 14 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.