Quand je viens d'utiliser de la pipe en bash, je n'y ai pas pensé davantage. Mais quand j'ai lu un exemple de code C utilisant pipe () d'appel système avec fork (), je me demande comment comprendre les pipes, y compris les pipes anonymes et les pipes nommées.

On entend souvent que "tout sous Linux / Unix est un fichier". Je me demande si un tuyau est en fait un fichier de sorte qu'une partie qu'il connecte écrit dans le fichier de tuyau, et l'autre partie lit le fichier de tuyau? Si oui, où est créé le fichier de canal pour un canal anonyme? Dans / tmp, / dev ou ...?

Cependant, à partir d'exemples de canaux nommés, j'ai également appris que l'utilisation de canaux présente un avantage en termes de performances spatiales et temporelles par rapport à l'utilisation explicite de fichiers temporaires, probablement parce qu'aucun fichier n'est impliqué dans l'implémentation de canaux. Les canaux semblent également ne pas stocker de données comme le font les fichiers. Je doute donc qu'une pipe soit en fait un fichier.

Concernant votre question de performances, les canaux sont plus efficaces que les fichiers car aucune E / S disque n'est nécessaire. Il cmd1 | cmd2est donc plus efficace que cmd1 > tmpfile; cmd2 < tmpfile(cela peut ne pas être vrai s'il tmpfileest sauvegardé sur un disque RAM ou un autre périphérique de mémoire en tant que canal nommé; mais s'il s'agit d'un canal nommé, il cmd1doit être exécuté en arrière-plan car sa sortie peut bloquer si le canal est plein ). Si vous avez besoin du résultat de cmd1et devez toujours envoyer sa sortie à cmd2, vous devriez cmd1 | tee tmpfile | cmd2autoriser cmd1et cmd2exécuter en parallèle en évitant les opérations de lecture sur disque cmd2.

Les canaux nommés sont utiles si de nombreux processus lisent / écrivent sur le même canal. Ils peuvent également être utiles lorsqu'un programme n'est pas conçu pour utiliser stdin / stdout pour son IO devant utiliser des fichiers . Je mets les fichiers en italique car les canaux nommés ne sont pas exactement des fichiers d'un point de vue de stockage car ils résident en mémoire et ont une taille de tampon fixe, même s'ils ont une entrée de système de fichiers (à des fins de référence). D'autres choses sous UNIX ont des entrées de système de fichiers sans être des fichiers: pensez simplement à /dev/nullou à d'autres entrées dans /devou /proc.

Comme les canaux (nommés et non nommés) ont une taille de tampon fixe, les opérations de lecture / écriture peuvent se bloquer, ce qui fait passer le processus de lecture / écriture dans l'état IOWait. De plus, quand recevez-vous un EOF lors de la lecture à partir d'un tampon mémoire? Les règles sur ce comportement sont bien définies et peuvent être trouvées chez l'homme.

Une chose que vous ne pouvez pas faire avec les canaux (nommés et non nommés) est la recherche dans les données. Comme ils sont implémentés à l'aide d'un tampon mémoire, cela est compréhensible.

À propos "everything in Linux/Unix is a file", je ne suis pas d'accord. Les canaux nommés ont des entrées de système de fichiers, mais ne sont pas exactement des fichiers. Les canaux sans nom n'ont pas d'entrées de système de fichiers (sauf peut-être dans /proc). Cependant, la plupart des opérations d'E / S sous UNIX sont effectuées à l'aide d'une fonction de lecture / écriture qui nécessite un descripteur de fichier , y compris un canal (et un socket) sans nom. Je ne pense pas que nous puissions dire cela "everything in Linux/Unix is a file", mais nous pouvons certainement le dire "most IO in Linux/Unix is done using a file descriptor".

Deux des principes fondamentaux de la philosophie UNIX sont

1. Faire de petits programmes qui font bien une chose.

2. et attendez-vous à ce que la sortie de chaque programme devienne l'entrée d'un autre programme,
   encore inconnu.

   L'utilisation de tuyaux vous permet de tirer parti des effets de ces deux
   principes fondamentaux de conception pour créer des chaînes de commandes extrêmement puissantes pour atteindre le résultat souhaité.

   La plupart des programmes en ligne de commande qui fonctionnent sur des fichiers peuvent également accepter une entrée sur entrée standard (entrée via le clavier) et une sortie sur sortie standard (impression à l'
   écran).

   Certaines commandes sont conçues pour fonctionner uniquement dans un canal et ne peuvent pas fonctionner directement sur les fichiers.

   par exemple trcommande

  ls -C | tr 'a-z' 'A-Z'

    cmd1 | cmd2

• Envoie STDOUT de cmd1 à STDIN de cmd2 au lieu de l'écran.

• STDERR n'est pas transmis à travers les tuyaux.

  En bref, vous Pipes is character (|)pouvez connecter des commandes.

  Toute commande qui écrit dans STDOUT peut être utilisée sur le côté gauche du tuyau.

     ls - /etc | less 

  Toute commande qui lit à partir de STDIN peut être utilisée sur le côté droit d'un tuyau.

     echo "test print" | lpr 

  Un canal traditionnel est "sans nom" car il existe de manière anonyme et ne persiste que tant que le processus est en cours d'exécution. Un canal nommé est persistant système et existe au-delà de la durée de vie du processus et doit être supprimé une fois qu'il n'est plus utilisé. Les processus s'attachent généralement au canal nommé (apparaissant généralement sous forme de fichier) pour effectuer la communication inter-processus (IPC).

source: http://en.wikipedia.org/wiki/Named_pipe

Pour compléter les autres réponses ...

stdin et stdout sont des descripteurs de fichiers et sont lus et écrits comme s'il s'agissait de fichiers. par conséquent, vous pouvez le faire echo hi | grep hi, et il remplacera la sortie standard d'écho par un tuyau et remplacera stdin de grep à l'autre extrémité de ce tuyau.

Tout est un fichier.

Si nous prenons l'expression trop à la lettre, nous finirions par avoir le sens de «nous n'avons que des fichiers et rien d'autre». Ce n'est pas la bonne interprétation, alors c'est quoi.

Lorsque nous disons «Tout est un fichier», nous ne disons pas que tout est stocké sur un disque. Nous disons que tout ressemble à un fichier, peut être lu, écrit.

Sous Unix, une fois qu'un fichier ou un non-fichier est ouvert, il peut être traité comme un fichier. Cependant, tous les fichiers ne prennent pas en charge toutes les opérations. Par exemple, certains fichiers (qui ne sont pas des fichiers), ne prennent pas en charge la recherche: ils doivent être lus / écrits dans l'ordre (c'est le cas des tuyaux et des sockets).

Tout a un nom de fichier (sur certains systèmes: par exemple Debian Gnu / Linux, et beaucoup d'autres Gnu / Linux).

• Tous les fichiers ouverts obtiennent un nom de fichier. Voir/proc/self/fd/…
• Les sockets réseau peuvent être ouvertes avec un nom de fichier, voir /dev/tcp
  par exemplecat </dev/tcp/towel.blinkenlights.nl/23