Linux/Datei/Pipe/Programmierung

Aus Foxwiki
Version vom 1. November 2026, 12:25 Uhr von Dirkwagner (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Programmierung in '''C''' == ; Verwendung einer unidirektionalen Unix-Pipe Dieser Sourcecode bewirkt das Gleiche wie die Shellanweisung <code>who | sort</code> <syntaxhighlight lang="c"> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> int main(void){ // pipe_verbindung[0] zum Lesen und pipe_verbindung[1] zum Schreiben int pipe_verbindung[2]; //Initialisierung durch die Funktion Pipe pipe(pipe_verbindung); //Kin…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

Programmierung in C

Verwendung einer unidirektionalen Unix-Pipe

Dieser Sourcecode bewirkt das Gleiche wie die Shellanweisung who | sort

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

int main(void){

// pipe_verbindung[0] zum Lesen und pipe_verbindung[1] zum Schreiben
int pipe_verbindung[2];

//Initialisierung durch die Funktion Pipe
pipe(pipe_verbindung);

//Kindprozess erzeugen
if (fork()==0){
    // dup2 verbindet den Filedeskriptor der Pipe mit dem Filedeskriptor der Standardausgabe
    dup2(pipe_verbindung[1],1);

    // der Leseausgang muss geschlossen werden, da dieser Prozess nichts liest
    close(pipe_verbindung[0]);

     // Kommando ausführen, Standardausgabe des Kommandos ist mit der Pipe verbunden
    execlp("who","who",NULL);
    }
// dann zweiten Kindprozess erzeugen
else if (fork()==0){
    dup2(pipe_verbindung[0],0);
    close(pipe_verbindung[1]);
    execlp("sort","sort",NULL);
    }
}
Schreibender Prozess

Prozess 1 hat zunächst auch lesenden Zugriff auf die Pipe (unidirektional)

  • Deshalb muss er seinen Filedeskriptor(0) zum Lesen sperren.
  • Genauso hat der lesende Prozess (Prozess 2) zunächst schreibenden Zugriff auf die Pipe.
  • Deshalb muss er seinen Filedeskriptor(1) zum Schreiben sperren.
Deskriptoren

Werden die nicht benötigten Deskriptoren nicht gesperrt, kommt es zu Komplikationen Wenn zum Beispiel Prozess 1 keine Daten mehr zu versenden hat, terminiert er.

  • Allerdings wird Prozess 2 nicht terminieren, da noch ein Filedeskriptor(1) zum Schreiben (sein eigener) für weitere Eingaben auf die Pipe gesetzt ist.
  • Er wartet, aber es kommen keine Daten.
Ein anderes denkbares Szenario

Prozess 1 kann nicht terminieren

  • weil er Lesezugriff auf die Pipe hat und für immer und ewig auf Daten des Gegenspielers wartet, aber niemals welche ankommen werden, da er erstens bereits terminiert ist und zweitens auch niemals welche gesendet hat

Windows

Windows kennt anonyme und benannte Pipes.
  • Benannte Pipes lassen sich über das Pipe-API analog zu den SMB-Freigaben als \\ServerName\pipe\PipeName ansprechen.

Anonyme Pipes sind in der Windows-Eingabeaufforderung möglich, um beispielsweise. mit dem find-Befehl in der Ausgabe eines dir-Befehls nur die Ausgaben zu erhalten, die bestimmte Zeichenketten im Pfad oder Dateinamen enthalten (was durch die dir-Syntax nicht immer vollständig abgedeckt ist): So gibt folgende Befehlseingabe alle Unterverzeichnisse mit enthaltenen .java Dateien aus, in denen im Pfad das Wort Render enthalten ist, sowie die .java Dateien selbst, in dessen Dateiname Render enthalten ist:

dir *.java /s | find "Render"