J'ai trébuché sur cette question, alors je me request comment est-ce possible?
Cycle de command standard:
# 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, essayons d'get la première ligne seulement:
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 | head -1 sent: 1; skipped: 0; total: 1
Qu'en est-il de la tête standard?
# 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
# zabbix_sender -c zabbix_agentd.conf -k mmysql.QCInserts -o 14 2>&1 | tee sent: 1; skipped: 0; total: 1
Je suis vraiment perplexe …
Cela peut se produire si l'application écrit directement dans le TTY au lieu de STDOUT ou STDERR.
Vous pouvez jouer avec ce comportement en comparant les 2 exemples ci-dessous
( echo foo ) &>/dev/null ( echo foo > $(tty) ) &>/dev/null
Notez que le premier ne montre rien, mais le second le fait. C'est parce que nous avons envoyé la sortie directement au tty et contourné la redirection vers /dev/null
.
Vous pouvez contourner ce genre de choses en utilisant le script
script -c '( echo foo > $(tty) ) &>/dev/null' >/dev/null
Fondamentalement, l'utilitaire de script
crée un faux tty et lance la command dans ce tty. Toute sortie de la command est envoyée à STDOUT que vous pouvez ensuite redirect normalement.