Zum Inhalt springen

Pipeline (Unix)

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 12. September 2018 um 22:44 Uhr durch Hundsrose (Diskussion | Beiträge) (Siehe auch: Formatierung). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Dieser Importartikel ist fälschlicherweise im Artikelnamensraum. Bitte verschiebe die Seite oder entferne diesen Baustein.
Dieser Artikel (Pipeline (Unix)) ist im Entstehen begriffen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.
Wenn du dies liest:
  • Der Text kann teilweise in einer Fremdsprache verfasst, unvollständig sein oder noch ungeprüfte Aussagen enthalten.
  • Wenn du Fragen zum Thema hast, nimm am besten Kontakt mit den Autoren auf.
Wenn du diesen Artikel überarbeitest:
  • Bitte denke daran, die Angaben im Artikel durch geeignete Quellen zu belegen und zu prüfen, ob er auch anderweitig den Richtlinien der Wikipedia entspricht (siehe Wikipedia:Artikel).
  • Nach erfolgter Übersetzung kannst du diese Vorlage entfernen und den Artikel in den Artikelnamensraum verschieben. Die entstehende Weiterleitung kannst du schnelllöschen lassen.
  • Importe inaktiver Accounts, die länger als drei Monate völlig unbearbeitet sind, werden gelöscht.
Eine auf einem Text-Terminal laufende Pipeline bestehend aus drei Programmen mit stdin, stdout und stderr

Eine Pipeline in unixoiden Betriebssystemen besteht aus durch ihre Standard-Datenströmen miteinander verketteten Prozessen, die für ihre Standardeingaben (stdin) die Standardausgaben (stdout) des jeweils vorherigen Prozesses verwenden. Der Name leitet sich von der physischen Pipeline ab.[1]

Im Standard der Shell-Syntax trennen Verkettungszeichen "|" (auch "Pipes" oder "Pipe-Characters" im Unix-Jargon genannt) die verschiedenen Prozesse:

 Prozess1 | Prozess2 | Prozess3

Jedes " | " verwendet dabei die im Betriebssystem bereits enthaltene (namenlose) Pipe für die Kommunikation zwischen den Prozessen .

Beispiel

Bestimme alle Dateien des aktuellen Verzeichnisses (ls), wähle nur den Teil der Ausgabe mit Zeichenkette "key" aus (grep) und gebe das Resultat zum seitenweisen Betrachten in der Kommandozeile aus (less) :

 ls -l | grep key | less

Standardfehlerausgabe

Per Default sammelt die Pipeline die Standardfehlerausgaben (stderr) ihrer einzelnen Kindprozesse und leitet sie am Ende an die Kommandozeile weiter. Die alternative Schreibweise "|&" der C-Shell führt jedoch die Standardausgaben und die Standardfehlerausgaben der jeweiligen Kindprozesse zusammen und übergibt diese als Standardausgabe an den nächsten Prozess.[2] Ergänzend dazu leitet die Pipeline in der Bourne-Shell seit Bash 4.0 die Standardfehlerausgaben mit der Notation 2>&1 in eine Datei um. [3]

Pipemill

In the most commonly used simple pipelines the shell connects a series of sub-processes via pipes, and executes external commands within each sub-process. Thus the shell itself is doing no direct processing of the data flowing through the pipeline.

However, it's possible for the shell to perform processing directly, using a so-called mill, or pipemill, (since a while command is used to "mill" over the results from the initial command). This construct generally looks something like:

command | while read var1 var2 ...; do
   # process each line, using variables as parsed into $var1, $var2, etc
   # (note that this may be a subshell: var1, var2 etc will not be available
   # after the while loop terminates; some shells, such as zsh and newer
   # versions of Korn shell, process the commands to the left of the pipe
   # operator in a subshell)
   done

Such pipemill may not perform as intended if the body of the loop includes commands, such as cat and ssh, that read from stdin:[4] on the loop's first iteration, such a program (let's call it the drain) will read the remaining output from command, and the loop will then terminate (with results depending on the specifics of the drain). There are a couple of possible ways to avoid this behavior. First, some drains support an option to disable reading from stdin (e.g. ssh -n). Alternatively, if the drain does not need to read any input from stdin to do something useful, it can be given < /dev/null as input.

Programm-Pipelines

Pipelines can be created under program control. The Unix pipe() Systemaufruf asks the operating system to construct a new anonymous pipe object. This results in two new, opened file descriptors in the process: the read-only end of the pipe, and the write-only end. The pipe ends appear to be normal, anonymous Datei-Handle, except that they have no ability to seek.

To avoid Deadlock (Informatik) and exploit parallelism, the Unix process with one or more new pipes will then, generally, call fork() to create new processes. Each process will then close the end(s) of the pipe that it will not be using before producing or consuming any data. Alternatively, a process might create a new "pthreads|thread" and use the pipe to communicate between them.

"Named pipes" may also be created using mkfifo() or mknod() and then presented as the input or output file to programs as they are invoked. They allow multi-path pipes to be created, and are especially effective when combined with standard error redirection, or with tee.

Geschichte

Douglas McIlroy führte die Pipeline während der Entwicklung von Unix in dessen Geburtsstätte Bell Labs als Teil der Unix-Philosophie ein.[5] nachdem er feststellte, dass die Unix-Shell sehr oft die Ausgabe-Datei eines Programms als Eingabe für ein anderes nutzte.

Im Jahr 1973 fügte Ken Thompson den Systemaufruf pipe() und für die Shell die Pipes der Version 3 Unix hinzu.[6]

Dieser führte außerdem die obige Notation ein, welche die Beschreibung der Pipe-Syntax in Version 4 Unix stark vereinfachte.[7]

Viele Betriebssysteme wie DOS, OS/2, Microsoft Windows, und BeOS implementierten später die Pipeline mit identischer Notation.

Die ursprüngliche Idee stammte jedoch von Ken Lochnerin, die bereits vor der Einführung von Unix in den 60er Jahren "communication files" im Betriebssystem Dartmouth Time Sharing System (DTSS) einführte.[8]

Tony Hoare entwickelte McIlroys Idee der Pipeline mit CSP weiter.[9]

Das Computerprogramm Automator von Apple verkettet auch sich wiederholende Befehle mit Pipelines. Das Roboter-Icon trägt daher als Hommage an das ursprüngliche Unix-Konzept ein Rohr (Pipe) in seinen Händen.

Siehe auch

  • Everything is a file – Grundpfeiler der Unix-Philosophie, Pipelines verarbeiten Dateien im Unix-Sinne
  • GStreamer – auf Pipelines basierendes Multimedia-Framework
  • GNU parallel - parallele Verarbeitung von mehreren Shells, auch mit Daten aus Pipes
  • Tee (Unix) – Unix-Befehl zum Abgreifen von Daten einer Pipeline
  • XML-Pipeline – Verarbeiten von XML-Dateien
  • xargs - Unix-Befehl um Standardausgaben via Pipe in andere Unix-Befehle umzuwandeln
  • netcat,socat Verbindung zu TCP/IP-Internet-Sockel mittels Pipes.

Einzelnachweise

  1. An Introduction to Linux I/O Redirection von Digital Ocean, Abschnitt Pipes
  2. C-Shell Quick Reference von Hamilton Laboratories
  3. Bash release notes von tiswww.case.edu (Case Western Reserve University), Abschnitt "New Features after Bash-3.2 release":1dd
  4. Shell Loop Interaction with SSH von archive.org
  5. Michael S. Mahoney: The Unix Oral History Project: Release.0, The Beginning.
  6. M. D. McIlroy ,1987 A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986, series=CSTR, number=139, Bell Labs
  7. Pipes: A Brief Introduction von The Linux Information Project (LINFO)
  8. http://www.cs.rit.edu/~swm/history/DTSS.doc
  9. https://swtch.com/~rsc/thread/ Bell Labs and CSP Threads (Russ Cox)


[[Kategorie:Unix]]