Provided by: manpages-fr_3.32d0.2p4-1_all bug

NOM

       pipe - Panorama des tubes et des FIFO

DESCRIPTION

       Les   tubes  et  les  FIFO  (ou  tubes  nommés)  fournissent  un  canal  de  communication
       interprocessus unidirectionnel. Un tube a une entrée et une sortie. Les données écrites  à
       l'entrée du tube peuvent être lues à sa sortie.

       Un  tube  est  créé avec l'appel système pipe(2), qui crée un nouveau tube et renvoie deux
       descripteurs de fichier, l'un correspondant à l'entrée du tube, et l'autre  à  la  sortie.
       Les  tubes  peuvent être utilisés pour créer un canal de communication entre des processus
       liés ; consultez pipe(2) pour un exemple.

       Un FIFO (abréviation de First In First Out) a un nom sur le système de fichiers (créé avec
       mkfifo(3)),  et  est  ouvert  avec  open(2).  Tout  processus  peut ouvrir un FIFO, si les
       permissions du fichier l'autorisent.  La  sortie  est  ouverte  avec  l'option  O_RDONLY ;
       l'entrée  est  ouverte  avec  l'option  O_WRONLY.  Consultez fifo(7) pour plus de détails.
       Note : même si les FIFO ont un nom sur le système de fichiers, les entrées/sorties sur  un
       FIFO n'impliquent pas d'opérations sur le périphérique sous‐jacent (s'il y en a un).

   E/S sur les tubes et les FIFO
       La  seule  différence  entre  les  tubes et les FIFO est la manière dont ils sont créés et
       ouverts. Une fois ces tâches accomplies, les E/S sur les tubes et les FIFO ont strictement
       les mêmes sémantiques.

       Si  un  processus  essaie  de  lire dans un tube vide, read(2) bloquera jusqu'à ce que des
       données soient disponibles. Si un processus essaie d'écrire dans un tube plein  (voir  ci‐
       dessous),  write(2)  bloque  jusqu'à ce que suffisamment de données aient été lues dans le
       tube avant de permettre la réussite de l'écriture. Des E/S non bloquantes  sont  possibles
       en utilisant l'opération F_SETFL de fcntl(2) pour activer l'attribut O_NONBLOCK.

       Le canal de communication fourni par un tube est un flot d'octets : il n'y a pas de notion
       de limite entre messages.

       Si tous les descripteurs de fichier correspondant à l'entrée d'un tube  sont  fermés,  une
       tentative  de  lecture  sur  le  tube  renverra  une  condition de fin de fichier (read(2)
       renverra 0). Si tous les descripteurs de fichier correspondant à la sortie d'un tube  sont
       fermés,  une  tentative  d'écriture  provoquera  l'envoi  du  signal  SIGPIPE au processus
       appelant. Si le processus appelant ignore ce signal, write(2) échoue avec l'erreur  EPIPE.
       Une  application  utilisant pipe(2) et fork(2) doit utiliser des appels à close(2) afin de
       fermer les descripteurs de fichier superflus ; ceci permet d'assurer que la  condition  de
       fin de ficher et SIGPIPE/EPIPE sont renvoyés correctement.

       Il n'est pas possible d'invoquer lseek(2) sur un tube.

   Capacité d'un tube
       Un  tube  a  une capacité limitée. Si le tube est plein, un write(2) bloquera ou échouera,
       selon  que  l'attribut  O_NONBLOCK  est  activé  ou  non  (voir  ci‐dessous).  Différentes
       implémentations ont différentes limites de capacité des tubes. Les applications ne doivent
       pas dépendre d'une capacité particulière, mais être conçues pour qu'un  processus  lecteur
       lise  les données dès qu'elles sont disponibles, pour qu'un processus écrivain ne soit pas
       bloqué.

       Dans les versions de Linux antérieures à 2.6.11, la capacité d'un  tube  était  la  taille
       d'une  page  système  (p.ex.  4096 octets sur i386). Depuis Linux 2.6.11, la capacité d'un
       tube est de 65536 octets.

   PIPE_BUF
       POSIX.1-2001  indique  que  les  écritures  de  moins  que  PIPE_BUF octets  doivent  être
       atomiques : les données sont écrites dans le tube de façon contiguë. Les écritures de plus
       que PIPE_BUF peuvent ne pas être atomiques : le noyau peut entrelacer les données avec des
       données  écrites  par  d'autres processus. POSIX.1-2001 demande que PIPE_BUF soit au moins
       512 octets. (Sous Linux, PIPE_BUF vaut  4096 octets.)  La  sémantique  précise  dépend  de
       l'attribut non-bloquant du descripteur de fichier (O_NONBLOCK), du nombre d'écrivains dans
       le tube, et de n, le nombre d'octets à écrire :

       O_NONBLOCK désactivé, n <= PIPE_BUF
              Les n octets sont écrits de manière atomique ; write(2) peut bloquer s'il n'y a pas
              de place pour écrire n octets immédiatement.

       O_NONBLOCK activé, n <= PIPE_BUF
              S'il  y  a la place d'écrire n octets dans le tube, write(2) réussit immédiatement,
              en écrivant les n octets ; sinon, write(2) échoue, et fixe errno à EAGAIN.

       O_NONBLOCK désactivé, n > PIPE_BUF
              L'écriture est  non  atomique :  les  données  fournies  à  write(2)  peuvent  être
              entrelacées  avec  des  écritures d'autres processus ; l'écriture bloque jusqu'à ce
              que n octets aient été écrits.

       O_NONBLOCK activé, n > PIPE_BUF
              Si le tube est plein, write(2) échoue, en plaçant errno à EAGAIN. Sinon, entre 1 et
              n octets  peuvent  être  écrits  (une  « écriture  partielle »  peut  se produire ;
              l'appelant doit vérifier la valeur de retour de write(2) pour voir combien d'octets
              ont  réellement  été  écrits),  et  ces  octets  peuvent  être  entrelacés avec des
              écritures d'autres processus.

   Attributs d'état de fichier ouvert
       Les seuls attributs d'état de fichier ouvert qui peuvent s'appliquer aux tubes et aux FIFO
       sont O_NONBLOCK et O_ASYNC.

       Activer  l'attribut  O_ASYNC à la sortie d'un tube provoque l'envoi d'un signal (SIGIO par
       défaut) lorsque de nouvelles données sont disponibles sur le tube (consultez fcntl(2) pour
       les  détails).  Sous Linux, O_ASYNC n'est possible sur les tubes et les FIFO que depuis le
       noyau 2.6.

   Notes sur la portabilité
       Sur certains systèmes (mais pas sous Linux), les tubes sont bidirectionnels : des  données
       peuvent  être  transmises  dans  les  deux  directions  entre  les  bouts  du  tube. Selon
       POSIX.1-2001, les tubes sont uniquement décrits comme unidirectionnels.  Les  applications
       portables doivent éviter de s'appuyer sur une sémantique bidirectionnelle des tubes.

VOIR AUSSI

       dup(2), fcntl(2), open(2), pipe(2), poll(2), select(2), socketpair(2), stat(2), mkfifo(3),
       epoll(7), fifo(7)

COLOPHON

       Cette page fait partie de la publication 3.32 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis   2010,   cette   traduction   est   maintenue   à   l'aide   de    l'outil    po4a
       <URL:http://po4a.alioth.debian.org/>  par  l'équipe  de  traduction francophone au sein du
       projet perkamon <URL:http://perkamon.alioth.debian.org/>.

       Christophe  Blaess  <URL:http://www.blaess.fr/christophe/>   (1996-2003),   Alain   Portal
       <URL:http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau et l'équipe francophone de
       traduction de Debian (2006-2009).

       Veuillez     signaler     toute     erreur     de     traduction     en     écrivant     à
       <debian-l10n-french@lists.debian.org>   ou   par   un  rapport  de  bogue  sur  le  paquet
       manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document  en  utilisant  la
       commande « man -L C <section> <page_de_man> ».