Cette question est traitée dans BashFAQ/032. Dans votre exemple, vous :
{ time sleep 1; } 2> /dev/null
La raison pour laquelle
time sleep 1 2>/dev/null
ne se comporte pas comme vous l'attendez parce qu'avec cette syntaxe, vous voudrez time la commande sleep 1 2>/dev/null (oui, la commande sleep 1 avec stderr redirigé vers /dev/null ). Le time intégré fonctionne de cette façon afin de rendre cela réellement possible.
Le bash intégré peut en fait le faire parce que... eh bien, c'est une fonction intégrée. Un tel comportement serait impossible avec la commande externe time généralement situé en /usr/bin . En effet :
$ /usr/bin/time sleep 1 2>/dev/null
$
Maintenant, la réponse à votre question
Pourquoi la sortie de certains programmes Linux ne va-t-elle ni à STDOUT ni à STDERR ?
est :c'est le cas, la sortie va à stdout ou stderr .
J'espère que cela vous aidera !
Votre question particulière sur time builtin a reçu une réponse, mais il existe certaines commandes qui n'écrivent pas non plus dans stdout ou à stderr . Un exemple classique est la commande Unix crypt . crypt sans argument chiffre l'entrée standard stdin et l'écrit sur la sortie standard stdout . Il demande à l'utilisateur un mot de passe en utilisant getpass() , qui génère par défaut une invite à /dev/tty . /dev/tty est le terminal actuel. Ecrire dans /dev/tty a pour effet d'écrire dans le terminal en cours (s'il y en a un, voir isatty() ).
La raison crypt impossible d'écrire dans stdout c'est parce qu'il écrit une sortie chiffrée dans stdout . Aussi, il est préférable d'inviter à /dev/tty au lieu d'écrire dans stderr de sorte que si un utilisateur redirige stdout et stderr , l'invite est toujours visible. (Pour la même raison, crypt impossible de lire le mot de passe de stdin , puisqu'il est utilisé pour lire les données à chiffrer.)