Qu'est-ce qu'un «tuyau» et comment le «casser»?

J'ai eu l'erreur "pipe cassée" de Xcode une fois de trop. Je suis maintenant curieux de savoir exactement ce qu'est une pipe.

Quel est le concept de «pipe» et comment peut-il être «cassé»?

Un canal est simplement un mécanisme de communication interprocessus (IPC) utilisé pour connecter la sortie standard d'un processus à l'entrée standard d'un autre.

Un exemple est lorsque vous souhaitez rechercher un mot pour le mot "pax" dans un fichier:

cat filename | grep pax

et oui, je sais que vous pouvez grepdirectement le fichier, mais cela n'explique pas comment cela fonctionne, n'est-ce pas?

Ceci connecte la sortie standard de la catcommande à l'entrée standard de la grepcommande. catenvoie le contenu du fichier à sa sortie standard et greplit son fichier (dans ce cas) à partir de son entrée standard. En connectant des processus comme celui-ci, vous pouvez créer vos propres outils composés de n'importe quel nombre de segments de tuyau. Des choses comme:

show_users | grep pax | awk -F: '{print $4}' | tr '[a-z]' '[A-Z]' | cut -c1-20

Un tuyau cassé est celui où (généralement) le destinataire des données a fermé la connexion pendant que l'expéditeur tente toujours d'envoyer des informations.

Par exemple, si vous envoyez un fichier volumineux via un programme de pager (pour le visualiser une page à la fois):

cat myfile | pager

puis faites un CTRL-BREAK, cela peut entraîner le pagerprocessus à fermer son canal d'entrée avant qu'il catait fini de l'utiliser. C'est une possibilité pour obtenir ce tuyau cassé.

D'après une recherche rapide sur Google , ce problème particulier semble être lié aux déploiements ad hoc et les solutions proposées incluent généralement la fermeture de la plupart de vos logiciels et le redémarrage de la plupart de vos appareils.

C'est probablement assez grave pour signaler le problème à Apple. Plus il y a de développeurs qui s'en plaignent, plus il y a de chances que quelque chose soit fait pour y remédier.

Le |personnage est souvent appelé une pipe. Dans les différents shells UNIX (que je connaisse), il peut être utilisé pour diriger la sortie d'une commande vers l'entrée d'une autre.

cat myfile.txt | head

La headcommande n'affiche que les premières lignes de son entrée. À ce stade, il ferme son entrée. Cela pose un problème pour la commande qui générait l'entrée. Où écrit-il? Chaque fois que nous avons cette situation, ou la situation où le processus d'écriture se termine avant la fin du lecteur, cela s'appelle un «tuyau cassé».

Pour éviter que la catcommande ne reste indéfiniment, la norme UNIX définit un signal spécial ( SIGPIPE , signal 13 ) auquel elle est envoyée cat. L'action par défaut pour ce signal est de tuer le processus, ce qui rend bien la catfin.

Il semble que l'application que vous utilisez ait installé un gestionnaire de signaux pour tous les signaux, y compris SIGPIPE, ce qui crée le petit message contextuel que vous voyez.

Cette erreur semble se produire assez souvent. /programming/490366/ad-hoc-deployment-issue-putpkt-write-failed-broken-pipe c'est "... une erreur interne dans la capacité de Xcode à parler à votre téléphone. Ce n'est pas le cas signifie que vous avez fait quelque chose de mal, c'est un bug dans le système de développement "

Un canal est un mécanisme IPC sur les systèmes Unix. Un tuyau a deux extrémités, une extrémité en lecture et une extrémité en écriture. Les données qui sont écrites dans la fin d'écriture peuvent être lues à partir de la fin de lecture et sortent dans l'ordre dans lequel elles ont été écrites.

Dans le monde en ligne de commande Unix, les canaux sont un moyen très courant de connecter des programmes pour faire un travail. Par exemple sed 's/foo/bar/g' fred.txt | grep -e 'bar.*baz'va lire dans le fichier fred.txtremplacer toutes les instances de la chaîne foopar la chaîne barpuis rechercher le résultat pour les lignes qui contiennent barsuivies d'un certain nombre de caractères, puis baz.

Bien sûr, cela ne semble pas terriblement utile. Mais je suis sûr que si vous y réfléchissez, vous pouvez voir comment vous pourriez être en mesure de mettre cela à toutes sortes d'utilisations intéressantes, surtout une fois que vous avez des programmes comme awkou perlà votre disposition.

Le système de tuyaux fait partie d'Unix depuis très tôt. Et si un processus de votre pipeline se termine, vous souhaitez généralement que tous les programmes du pipeline se terminent. Cela signifie que, par défaut, un processus qui écrit dans un canal où le processus à la fin de la lecture a disparu recevra un SIGPIPEsignal. Et si son bloqué ce signal, le writeéchouera toujours avec un type d'erreur particulier indiquant que le tuyau a «cassé».

La gestion par défaut de SIGPIPEtue le processus qui le reçoit. Et si ce n'est pas la «tête» du pipeline, le tout SIGPIPEse propage en remontant la chaîne.

Ce dont Xcode se plaint, c'est qu'il a démarré un sous-programme pour faire quelque chose avec un tuyau qui y mène, et que ce sous-programme est mort de façon inattendue, laissant le tuyau cassé.

Un tuyau «cassé» est un tuyau dont une extrémité a été close()utilisée et l'autre est lue ou écrite. Par exemple, dans la commande shell suivante:

cat foo | less

Le catprocessus contient l'extrémité d'écriture du tuyau et le lessprocessus la lecture. Si le processus de lecture ferme le tuyau, le tuyau est cassé (et donc inutile); le processus d'écrivain recevra l'erreur «pipe cassée» du système d'exploitation.