J'ai été surpris au début. Cependant, après avoir lu les réponses et fait une petite enquête, cela semble simple. Voici donc ce que j'ai trouvé. (à la fin il n'y a pas eu de surprise.)
Avant la redirection, stdin, stdout et stderr sont, comme prévu, connectés au même périphérique.
#ctrl-alt-delor:~$
#↳ ll /dev/std*
lrwxrwxrwx 1 root root 15 Jun 3 20:58 /dev/stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Jun 3 20:58 /dev/stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Jun 3 20:58 /dev/stdout -> /proc/self/fd/1
#ctrl-alt-delor:~$
#↳ ll /proc/self/fd/*
lrwx------ 1 richard richard 64 Jun 30 19:14 /proc/self/fd/0 -> /dev/pts/12
lrwx------ 1 richard richard 64 Jun 30 19:14 /proc/self/fd/1 -> /dev/pts/12
lrwx------ 1 richard richard 64 Jun 30 19:14 /proc/self/fd/2 -> /dev/pts/12
Par conséquent, après la plupart des réorientations (c'est-à-dire si stderr) n'est pas redirigé. stderr est toujours connecté au terminal. Par conséquent, il peut être lu pour obtenir une entrée au clavier.
La seule chose qui arrête les fichiers utilisés dans le sens inattendu est la convention et les canaux sont unidirectionnels.
Un autre exemple, essayez:
cat | less
Cela se passe mal après une page, lors d'une less
tentative de lecture du terminal (ce n'est pas une surprise, tout comme la cat
lecture du terminal).
/dev/tty
est plus mystérieux, ce n'est pas un lien vers /proc/self
.
#ctrl-alt-delor:~$
#↳ ll /dev/tty
crw-rw-rw- 1 root tty 5, 0 Jun 29 09:18 /dev/tty
Voir quelles sont les relations entre mon terminal de contrôle actuel et `/ dev / tty`? pour une explication. Merci à @StephenKitt pour le lien.
/dev/tty
, voir cette question .