Diskussion:Pipe (Informatik)

Pipe Bild

Ich kann Euch ein Bild zur Verfügung stellen...., wollte es schon hochladen aber das darf ich ja nicht.. ;)

Pipe vs. Pipe (Informatik)

Findet sich ein Fachkundiger (TI), der mal die beiden Artikel Pipe und Pipe (Informatik) durchliest und einen draus macht oder die zusammengehörigen Teile entsprechend sortiert? Wäre super :) --Pinguin.tk 15:08, 8. Jun 2004 (CEST)

mhh... RPC : Remote Process Communication ist eine eher ungebräuchliche Abkürzung... es sollte wohl eher Remote Procedure Call heissen - welcher zur IPC=Interprozesskommunikation zählt. Insgesamt wäre es schöner, nicht nur OS/2 hier so hervorzuheben, da Pipes (in unterschiedlichen Varianten) auch in UNIX/Linux und sogar in DOS/Windows verfügbar sind. --Wiedemann 07:09, 11. Jun 2004 (CEST)

Dieser Artikel wurde von mir überarbeitet und in den Artikel pipe integriert, danach hier ein redirect darauf angelegt. Näheres zu den Gründen in der Diskussion zu Pipe --Friese 22:10, 17. Jun 2004 (CEST)

Habe den informatischen Teil von Pipe nach Pipe (Informatik) verschoben und aus Pipe eine Begriffsklärung gemacht. --Zupftom 22:53, 16. Nov 2005 (CET)

Der Artikel ist noch sehr für Fachleute zugeschnitten und für relative Laien unverständlich. Dabei wäre das Thema im hier erläuterten Zusammenhang eigentlich gar nicht so sehr kompliziert. Da ich mich selbst aber nicht sehr sicher fühle, würde ich es begrüßen, wenn ein Fachmann den einleitenden Text so formuliert, dass ihn auch jemand versteht, der gerade mal sein erstes Linux "aufgesetzt" hat. Ob ein Systemaufruf wirklich gleich ganz am Anfang erwähnt werden muss? Ich denke ggf. eher an eine kleine Grafik mit zwei Prozessen und Daten- bzw. Fehlerkanal und verständliche Formulierungen ohne Anglizismen. Wünschenswert fände ich auch, wenn auf das Multiplexen besser eingegangen wird.

Habe mal die Einleitung etwas ausgebaut. Dadurch nun etwas Redundanz, aber vielleicht werden jetzt weniger Laien nach der Einleitung aufgeben. Ist das so verständlicher, oder muss man das noch ausbauen (bin leider schon zu lange in der Thematik drin)? Oder ist es schon zu viel für eine Einleitung? Wäre vielleicht ein Diagramm mit Beispielausgaben hilfreich? Bitte um konstruktive Kritik! --80.136.82.164 16:59, 2. Aug. 2007 (CEST)

Versionsgeschichte

In diesem Artikel wurden mehrere Versionen aufgrund von DDR-URV gelöscht. Anbei die komplette Versionsgeschichte:

• 14:52, 21. Nov 2005 193.175.213.20 (→Unix)
• 22:38, 16. Nov 2005 Zupftom (Hierher verschoben wegen Begriffsklärung auf Pipe)

und aus Pipe:

• 22:43, 16. Nov 2005 Zupftom (Informatischer Teil nach Pipe (Informatik) verschoben)
• 06:00, 21. Okt 2005 145.254.110.38 (→Weitere Bedeutung)
• 05:50, 21. Okt 2005 145.254.110.38 (→Weitere Bedeutung)
• 22:08, 11. Okt 2005 85.212.131.1 (→Pipes in Betriebssystemen)
• 16:58, 1. Okt 2005 84.130.46.44 (→Pipes in Betriebssystemen - typo)
• 15:16, 22. Sep 2005 Sparti K (kat)
• 14:10, 14. Sep 2005 Bera K (Tippfehler)
• 20:22, 20. Aug 2005 Civvi K (+ it)
• 13:30, 8. Aug 2005 212.183.19.130 (→Pipes in Betriebssystemen)
• 13:30, 8. Aug 2005 212.183.19.130 (→OS/2)
• 13:29, 8. Aug 2005 212.183.19.130 (→Pipes in Betriebssystemen)
• 00:44, 30. Jul 2005 80.146.34.93 (→Unix - so wäre das Beispiel auch in EINER Shell einzugeben. Hat vorher etwas verwirrt (mich))
• 13:42, 12. Jul 2005 Wiedemann (→Unix)
• 23:30, 26. Apr 2005 83.135.201.8 (Nerdblindheit removed :-))
• 18:41, 6. Apr 2005 84.178.47.118 (→Unix)
• 10:17, 15. Feb 2005 JakobVoss (Weblink)
• 00:01, 7. Feb 2005 Sparti K (Kategorie)
• 19:06, 31. Jan 2005 DuesenBot K (Bot-unterstützte Begriffsklärung: Puffer)
• 14:45, 3. Dez 2004 DerFlo (→Unix)
• 23:45, 22. Nov 2004 Neg (+en:)
• 13:25, 12. Nov 2004 MichaelDiederich K (MichaelDiederich - Bot-unterstützte Redirectauflösung: Computernetzwerk)
• 23:11, 1. Nov 2004 BWBot K (Bananeweizen - Bot: Typo)
• 13:04, 29. Okt 2004 DerFlo (→Unix)
• 11:52, 7. Okt 2004 84.128.96.189 (→Pipes in Betriebssystemen)
• 13:13, 17. Sep 2004 Sprezzatura K (kat. & format)
• 09:43, 26. Aug 2004 HarryHT K (nur redaktionelle Änderungen)
• 22:02, 30. Jun 2004 217.235.95.146 (typo)
• 19:14, 27. Jun 2004 217.83.138.79
• 19:46, 22. Jun 2004 Richie K (→Unix: Shell --> Kommandozeileninterpreter)
• 15:18, 18. Jun 2004 Wmeinhart K (→Weitere Bedeutung - wikif.)
• 13:54, 18. Jun 2004 Frank Jacobsen (linkfix)
• 22:25, 17. Jun 2004 Wmeinhart (→Weitere Bedeutung -kimberlitpipes)
• 22:04, 17. Jun 2004 Frank Jacobsen (erw)
• 21:40, 17. Jun 2004 Frank Jacobsen (siehe Diskussion, aus Pipe (Informatik))

• 21:42, 17. Jun 2004 Frank Jacobsen (redir Pipe Inhalt dorthin ausgelagert)
• 14:05, 8. Jun 2004 Pinguin.tk (unterschied zu pipe?)
• 13:56, 8. Jun 2004 Pinguin.tk (wikifiziert)
• 14:19, 3. Apr 2004 217.83.14.47 (DDR-URV) --Schwalbe ^Disku 10:48, 2. Jan 2006 (CET)

Unidirektional

Stimmt das "unidirektional" im Einleitungssatz? Die benannten Pipes sind doch gemäß der Erklärung weiter unten in Artikel bidirektional.--Harmonica 02:46, 9. Jan 2006 (CET)

Hallo Harmonica, du hast Recht. Ich habe das "unidirektional" zu den anonymen Pipes verschoben. Gruß, Langec ☎ 11:50, 9. Jan 2006 (CET)

Pipes im Arbeitsspeicher und als Datei?

Sicherlich sind den einen oder anderen die Anfänge wie DOS noch im Hinterkopf. Dabei gab es dort Dateien die bei der Datenübergabe von Daten von einem zum anderen Programm gedient haben. Diese dienen dort sozusagen als Pipe und wurden dort auch in der Dokumentation oft auch Pipefile genannt (*.$01, *.$02, ... , *.$XX). Ich mag zwar etwas pingelig sein aber ein direkter Austausch von Daten nach dem Prinzip "Du, ich habe da was" <Was?> "*Adresse gebe* Das da" ist es ja irgendwie doch aber - ist das ein richtiges "Pipen" oder nur eine altmodische Lösung?

Es ist weder „richtiges pipen“ oder eine „almodische Lösung“, sondern war damals wie heute nur eine absolute Notlösung. Datenübergabe macht man per FIFO oder eben mittels Pipe. Temporäre Dateien sollten nur in Ausnahmefällen verwendet werden, oder wenn das zu erledigende nicht anders lösbar ist, da z.B. nicht alle Daten auf ein mal Verfügbar sind, oder von mehreren Programmen verwendet werden sollen. --^icewind^ 23:58, 22. Nov. 2008 (CET)

„Useless use of cat“

Gerade in Verbindung mit mit grep wird cat immer gerne verwendet, wobei es …

grep SUCHBEGRIFF DATEI

… in 99 Prozent der Fälle genau so tut.

Mir ist durchaus bewusst, dass es hier um ein Beispiel der Verwendung einer Pipe geht, aber sollte man als Beispiel nicht etwas anderes nehmen, als DAS Negativbeispiel der zu demonstrierenden Technik schlechthin?

--^icewind^ 23:55, 22. Nov. 2008 (CET)

Die Eingabeumleitung fuer grep zu verwenden hat beim gescripteten Generieren von Texten (auch von Scripts) manchmal den Vorteil, dass nicht erst ein Dateiname abgeschnibbelt werden muss, um den reinen Inhalt der Suche zu bekommen. Interessant und recht maechtig finde ich auch die Pipe-Verwendung in Informix-SQL, also output to pipe <kommando> without headings. Als Kommando wird zwar vermutlich in 99% der Faelle das hier angesprochene "cat" verwendet, man kann aber auch viel maechtigere Kommandos darin unterbringen (z.B. on-the-fly Konvertierungen). -- 195.14.235.53 11:42, 25. Mai 2014 (CEST)

"alte" Pipe

Ich habe so eine verschwommene Erinnerung, dass man frueher auch das Caret (den einzelnen Circumflex ohne was drunter) als Pipe verwenden konnte oder sogar musste - koennte Sinix oder Xenix 286 (Nachtrag : evtl. auch Minix) gewesen sein. Weiss das noch jemand? -- 213.168.96.159 20:34, 27. Jun. 2011 (CEST)

Pipe und Windows?

Es ist ja schon ein kleiner Abschnitt für Windows enthalten, aber dieser könnte durchaus vergrößert werden.

Ist es nicht so, dass man bei CMD-Befehlen von Windows auch eine Art Pipes nutzen kann. Bspw. so:

 dir | sort

Dies listet z.B. alle Daten im aktuellen Ordner auf und übergibt diese (im STDOUT-Stream enthaltenen Daten) dann (durch den STDIN-Stream) an sort.

Evt. zählt >, < und co auch als Pipe.

Mehr Informationen:

• [1]
• [2]

Geschichte: Data Massage

Kann ich bitte eine Data Massage haben?

„We should have some ways of connecting programs like garden hose--screw in another segment when it becomes necessary to massage data in another way.“ --131.188.30.102 15:10, 11. Jun. 2024 (CEST)

Named pipe

"wenn ein schreibender Prozess sein Ende der Pipe schließt," - gibt's dafür (für's Schließen einer pipe) ein Kommando (analog zu mkfifo) oder passiert das nur automatisch, wenn der Prozess zu Ende ist? --46.57.88.65 15:30, 9. Jul. 2024 (CEST)

rm <name> ‣Andreas•⚖ 20:41, 9. Jul. 2024 (CEST)

Okay, das war zu kurz gegriffen. mkfifo macht eine Datei im Dateisystem, allerdings ist das eine virtuelle Datei. Die Named Pipe wird durch die Datei im Dateisystem repräsentiert (Unix: everything is a file, alles ist eine Datei). Öffnet nun ein Prozess die Datei schreibend, so ist dieses "Ende" (das befüllende, da ja schreibend) "geöffnet". Das ist aber wie bei jeder anderen Datei auch: wenn ein Programm eine Datei noch benutzt, kann man diese auch nicht löschen. Bei der Named pipe kommt hinzu, dass die Daten, die in der Pipe vorgehalten werden, solange vorgehalten werden, solange eines der Enden geöffnet ist. Wenn nun ein anderer Prozess dieselbe Datei, die ja eine Named Pipe ist, lesend öffnet, so ist eben dieses Ende "geöffnet". Wenn beide Enden, das heißt, der schreibende und der lesende Prozess, geschlossen werden, gehen alle Daten in der Pipe verloren. Die Datei im Dateisystem selbst bleibt aber erhalten, nur eben, dass sie keine Daten mehr enthält, was dem Zustand gleich nach mkfifo entspricht, wo die Datei erstellt wurde. Um die Repräsentation einer Named Pipe, das ist die Datei, wieder loszuwerden, muss man diese -- wie jede andere Datei auch -- einfach nur löschen. Also mit rm z.B....

‣Andreas•⚖ 20:53, 9. Jul. 2024 (CEST)

Ok, danke!

Das ist -- für einen Halb-Laien -- schon viel verständlicher als das vorhandene "FIFOs überdauern die sie verwendenden Prozesse, weil sie Bestandteil des Dateisystems sind. Allerdings kann eine FIFO keinen Inhalt haben, solange sie von keinem Prozess geöffnet ist. Das bedeutet, dass der gepufferte Inhalt verloren geht, wenn ein schreibender Prozess sein Ende der Pipe schließt, ohne dass ein lesender Prozess das andere Ende geöffnet hat."

Es bleibt noch die Frage: Wie "schließt ein schreibender Prozess sein Ende der Pipe"? --46.57.88.65 14:03, 10. Jul. 2024 (CEST)

Wenn ein Prozess eine Datei, die eine Named Pipe ist, öffnet, wird die Pipe aktiviert.

user@hostname:/tmp$ mkfifo /tmp/NamedPipe

user@hostname:/tmp$ echo "Viel, viel Text..." > /tmp/NamedPipe &

Hier hat das Kommando echo die Named Pipe geöffnet, Text hineingeschrieben, und wieder geschlossen. Nun muss noch ein lesender Prozess die "Datei" /tmp/NamedPipe öffnen, damit sie von beiden Seiten einmal verwendet wurde -- darum muss man echo hier mit dem & starten, weil die Kommandozeile sonst blockiert wäre: die Pipe wartet nämlich, bis der andere Teil (in diesem Fall der lesende) auch was macht. Alternativ kann man das eine Kommando in einer Shell, das andere Kommando in einer anderen Shell starten.

user@hostname:/tmp$ cat /tmp/NamedPipe

Viel, viel Text...

Der lesende Teil hat die Pipe vervollständigt, beide Prozesse die Datei wieder geschlossen (weil das echo und cat eben so machen), und damit ist die Named Pipe wieder leer: das heißt, sie ist bereit, nochmal verwendet zu werden, oder man kann die Datei wieder löschen.

Das ganze funktioniert von beiden Seiten, man kann also mit dem lesenden Prozess anfangen:

user@hostname:/tmp$ cat /tmp/NamedPipe &

user@hostname:/tmp$ echo "Viel, viel Text..." > /tmp/NamedPipe

Viel, viel Text...

Wenn nur einer der beiden Prozesse die Datei nicht gleich wieder freigibt, bleibt die Pipe bestehen, wobei es egal ist, ob von der schreibenden oder der lesenden Seite. Es muss ja auch nicht jedes Kommando die Datei gleich wieder schließen, wie es bei echo und cat der Fall ist.

Das mit dem Sperren der Datei hatte ich jedoch falsch. Die Repräsentation der Named Pipe, also die Datei selbst, lässt sich jederzeit löschen, auch dann, wenn sie von einer Seite bereits geöffnet wurde:

user@hostname:/tmp$ cat /tmp/NamedPipe &

user@hostname:/tmp$ rm /tmp/NamedPipe

user@hostname:/tmp$ ps -A | grep cat

123456 pts/1 00:00:00 cat

Man sieht allerdings, dass der Prozess, der auf die Named Pipe "wartet", nun 1. nicht beendet wurde, und nun 2. ewig warten wird (müssen)... oder zumindest so lange als Prozess weiterbesteht, wie die Subshell selbst besteht, also z.B. die Terminalemulation offen bleibt. Bei einer Terminalemulation werden alle darin laufenden Prozesse mit dem Shell-Fenster gemeinsam auch wieder geschlossen, weil sie auf die Subshell der Terminalemulation beschränkt sind, bzw. als Sub-Prozesse dieser im Fenster laufenden Shell gestartet wurden).

‣Andreas•⚖ 14:31, 10. Jul. 2024 (CEST)

Jetzt ist's ziemlich klar. Danke! --46.57.88.65 21:28, 12. Jul. 2024 (CEST)