Deux fenêtres, même utilisateur, avec des invites bash. Dans le type de fenêtre 1:
$ mkfifo f; exec <f
Donc bash tente maintenant de lire à partir du descripteur de fichier 0, qui est mappé sur le canal nommé f
. Dans le type de fenêtre 2:
$ echo ls > f
Maintenant, window-1 imprime un ls puis le shell meurt. Pourquoi?
Expérience suivante: ouvrez à nouveau la fenêtre-1 avec exec <f
. Dans le type de fenêtre 2:
$ exec 3>f
$ echo ls >&3
Après la première ligne ci-dessus, la fenêtre-1 se réveille et imprime une invite. Pourquoi? Après la deuxième ligne ci-dessus, window-1 imprime la ls
sortie et le shell reste vivant. Pourquoi? En fait, maintenant dans la fenêtre-2, echo ls > f
ne ferme pas le shell de la fenêtre-1.
La réponse doit avoir à voir avec l' existence du descripteur de fichier 3 de la fenêtre 2 référençant le canal nommé?!
exec 3>f
exécuté, le premier shell donne ensuite une invite. (Point mineur, vouliez-vous dire "en mode écriture " dans votre commentaire?)
exec <f
,bash
on ne cherche pas à lire à partirf
, il est d' abord tenté d' ouvrir il. Leopen()
ne reviendra pas tant qu'il n'y aura pas de processus faisant une autre ouverture en mode écriture dans le tuyau (à quel moment le tuyau sera instancié et le shell lira les entrées de celui-ci).