Pourquoi la redirection de fichiers vers et depuis un canal nommé ne fonctionne-t-elle pas, contrairement à la canalisation vers cat?

Il s'agit d'un simple serveur d'écho sous Unix, utilisant nc:

mkfifo fifo
cat fifo | nc -k -l 4458 -v | cat >fifo

(basé sur cela )

Comme je peux le voir, le flux de données fonctionne comme suit:

fifo (my named pipe)
 |
 | (using cat)
 |
 v
nc
 |
 | (using cat)
 |
 v
fifo

Et voici la question: pourquoi ça ne marche pas?

nc -k -l 4458 -v >fifo <fifo

Vous remarquerez que si vous essayez de le telnetfaire localhost, 4458vous obtiendrez une erreur "Connexion refusée".

pipe socket fifo Razvan
la source

Je n'ai pas de réponse mais j'espère que cela pourrait aider quelqu'un de mieux informé que moi. cat myfifo | nc -k -l 4458 > myfifofonctionne également. Si vous utilisez un fichier texte, file.txt comme ceci nc -k -l 4458 < file.txt > file.txtLa première connexion se connectera et se fermera (est logique parce que l'entrée a été tronquée et EOF ferme le socket), la deuxième connexion deviendra un serveur d'écho oublieux: il fera écho toutes les deux lignes et enregistrez les lignes sans écho dans le fichier texte.

user1794469

Réponses:

C'est parce que la commande netcat n'a même pas encore commencé! Le shell lorsque vous essayez d'ouvrir le fifo pour l'entrée se bloque. Essayer

strace cat >fifo <fifo

et vous ne verrez rien. Utilisez plutôt, par exemple,

nc -k -l 4458 -v <>fifo >&0

qui ouvre le fifo pour lire et écrire en tant que stdin, puis le dups à stdout.

Le suivi de la commande bash complète montre que ni l'ouverture en lecture ni en écriture ne revient (jusqu'à ce que l'ouverture opposée soit terminée):

$ strace -f -e open bash -c 'nc -k -l 4458 -v  >fifo <fifo'
...
Process 3631 attached
[pid  3631] open("fifo", O_WRONLY|O_CREAT|O_TRUNC, 0666

$ strace -f -e open bash -c 'nc -k -l 4458 -v  <fifo >fifo'
...
Process 3684 attached
[pid  3684] open("fifo", O_RDONLY

man 3 mkfifo: Ouvrir un FIFO pour lire normalement se bloque jusqu'à ce qu'un autre processus ouvre le même FIFO pour l'écriture, et vice versa.

meuh
la source

Le blocage est documenté: tldp.org/LDP/lpg/node19.html

jusqu'au

Pourquoi le shell se bloque-t-il lors de l'utilisation de "> fifo <fifo"? Il semblerait qu'il l'ouvre pour l'écriture puis pour la lecture. Donc, comme il y a déjà une poignée pour l'écriture ouverte, ne devrait-elle pas continuer normalement?

Razvan

@Razvan J'ai mis à jour la réponse avec la strace réelle pour les deux ordres alternatifs d'ouverture du fifo, et vous pouvez le voir ouvert pour écrire ou lire les deux blocs.

meuh