Was sind stdin, stdout und stderr unter Linux?

stdin , stdout und stderr sind drei Datenströme, die erstellt werden, wenn Sie einen Linux-Befehl starten. Sie können sie verwenden, um festzustellen, ob Ihre Skripts weitergeleitet oder umgeleitet werden. Wir zeigen Ihnen wie.

Streams verbinden zwei Punkte

Sobald Sie anfangen, sich mit Linux und Unix-ähnlichen Betriebssystemen zu beschäftigen, werden Sie auf die Begriffe stdin , stdout und stederr . Dies sind drei Standard-Streams, die aufgebaut werden, wenn ein Linux-Befehl ausgeführt wird. Beim Rechnen ist ein Stream etwas, das Daten übertragen kann. Bei diesen Streams handelt es sich bei diesen Daten um Text.

Datenströme haben wie Wasserströme zwei Enden. Sie haben eine Quelle und einen Abfluss. Unabhängig davon, welchen Linux-Befehl Sie verwenden, wird ein Ende jedes Streams bereitgestellt. Das andere Ende wird von der Shell bestimmt, die den Befehl gestartet hat. Je nach Befehlszeile, die den Befehl gestartet hat, wird dieses Ende mit dem Terminalfenster verbunden, mit einer Pipe verbunden oder zu einer Datei oder einem anderen Befehl umgeleitet.

Die Linux-Standardstreams

Unter Linux ist stdin der Standard-Eingabestream. Dies akzeptiert Text als Eingabe. Die Textausgabe des Befehls an die Shell wird über den stdout -Stream (Standardausgabe) geliefert. Fehlermeldungen des Befehls werden über den stderr -Stream (Standardfehler) gesendet.

Sie können also sehen, dass es zwei Ausgabestreams, stdout und stderr , und einen Eingabestream, stdin , gibt. Da Fehlermeldungen und normale Ausgabe jeweils einen eigenen Kanal haben, um sie zum Terminalfenster zu transportieren, können sie unabhängig voneinander behandelt werden.

Streams werden wie Dateien behandelt

Streams werden unter Linux – wie fast alles andere – so behandelt, als wären sie Dateien. Sie können Text aus einer Datei lesen und Text in eine Datei schreiben. Beide Aktionen beinhalten einen Datenstrom. Das Konzept, einen Datenstrom als Datei zu handhaben, ist also nicht so weit hergeholt.

Jeder Datei, die einem Prozess zugeordnet ist, wird eine eindeutige Nummer zugewiesen, um sie zu identifizieren. Dies wird als Dateideskriptor bezeichnet. Wann immer eine Aktion für eine Datei ausgeführt werden muss, wird der Dateideskriptor verwendet, um die Datei zu identifizieren.

Diese Werte werden immer für stdin , stdout, und stderr verwendet:

• 0 : stdin
• 1 : Standardausgabe
• 2 : stderr

Reagieren auf Pipes und Redirects

Um jemandem den Einstieg in ein Thema zu erleichtern, besteht eine gängige Technik darin, eine vereinfachte Version des Themas zu unterrichten. Zum Beispiel wird uns bei der Grammatik gesagt, dass die Regel „I vor E, außer nach C“ lautet. Aber tatsächlich gibt es mehr Ausnahmen von dieser Regel als Fälle, die ihr gehorchen.

In ähnlicher Weise ist es praktisch, wenn man über stdin , stdout und stderr spricht, das akzeptierte Axiom herauszustellen, dass ein Prozess weder weiß noch sich darum kümmert, wo seine drei Standard-Streams beendet werden. Sollte sich ein Prozess darum kümmern, ob seine Ausgabe an das Terminal geht oder in eine Datei umgeleitet wird? Kann es überhaupt erkennen, ob seine Eingabe von der Tastatur kommt oder von einem anderen Prozess dorthin geleitet wird?

Tatsächlich weiß ein Prozess Bescheid – oder kann es zumindest herausfinden, falls er sich für eine Überprüfung entscheidet – und er kann sein Verhalten entsprechend ändern, wenn der Softwareautor beschließt, diese Funktionalität hinzuzufügen.

Wir können diese Verhaltensänderung sehr leicht erkennen. Probieren Sie diese beiden Befehle aus:

 ls 

 ls | Katze 

Der Befehl ls verhält sich anders, wenn seine Ausgabe ( stdout ) in einen anderen Befehl geleitet wird. Es ist ls , das auf eine einzelne Spaltenausgabe umschaltet, es ist keine Konvertierung, die von cat durchgeführt wird. Und ls macht dasselbe, wenn seine Ausgabe umgeleitet wird:

 ls > capture.txt 

 cat-capture.txt 

Umleitung von stdout und stderr

Es hat den Vorteil, dass Fehlermeldungen von einem dedizierten Stream geliefert werden. Das bedeutet, dass wir die Ausgabe eines Befehls ( stdout ) in eine Datei umleiten können und trotzdem alle Fehlermeldungen ( stderr ) im Terminalfenster sehen können. Auf die auftretenden Fehler können Sie bei Bedarf reagieren. Es verhindert auch, dass die Fehlermeldungen die Datei kontaminieren, in die stdout umgeleitet wurde.

Geben Sie den folgenden Text in einen Editor ein und speichern Sie ihn in einer Datei namens error.sh.

 #!/bin/bash

echo "Über den Versuch, auf eine Datei zuzugreifen, die nicht existiert"
cat schlechter Dateiname.txt

Machen Sie das Skript mit diesem Befehl ausführbar:

 chmod +x error.sh

Die erste Zeile des Skripts gibt Text über den stdout -Stream an das Terminalfenster zurück. Die zweite Zeile versucht, auf eine Datei zuzugreifen, die nicht existiert. Dies erzeugt eine Fehlermeldung, die über stderr geliefert wird.

Führen Sie das Skript mit diesem Befehl aus:

 ./error.sh 

Wir können sehen, dass beide Ausgabeströme, stdout und stderr , in den Terminalfenstern angezeigt wurden.

Versuchen wir, die Ausgabe in eine Datei umzuleiten:

 ./error.sh > capture.txt 

Die Fehlermeldung, die über stderr geliefert wird, wird weiterhin an das Terminalfenster gesendet. Wir können den Inhalt der Datei überprüfen, um zu sehen, ob die stdout -Ausgabe in die Datei gegangen ist.

 cat-capture.txt 

Die Ausgabe von stdin wurde wie erwartet in die Datei umgeleitet.

Das Umleitungssymbol > funktioniert standardmäßig mit stdout . Sie können einen der numerischen Dateideskriptoren verwenden, um anzugeben, welchen Standardausgabestrom Sie umleiten möchten.

Verwenden Sie diese Umleitungsanweisung, um stdout explizit umzuleiten:

 1>

Verwenden Sie diese Umleitungsanweisung, um stderr explizit umzuleiten:

 2>

Versuchen wir es noch einmal mit unserem Test, und dieses Mal verwenden wir 2> :

 ./error.sh 2> capture.txt 

Die Fehlermeldung wird umgeleitet und die stdout echo an das Terminalfenster gesendet:

Mal sehen, was in der Datei capture.txt steht.

 cat-capture.txt 

Die stderr -Nachricht befindet sich wie erwartet in capture.txt.

Sowohl stdout als auch stderr umleiten

Wenn wir entweder stdout oder stderr unabhängig voneinander auf eine Datei umleiten können, sollten wir sie doch sicherlich beide gleichzeitig auf zwei verschiedene Dateien umleiten können?

Ja wir können. Dieser Befehl leitet stdout zu einer Datei namens capture.txt und stderr zu einer Datei namens error.txt.

 ./error.sh 1> capture.txt 2> error.txt 

Da beide Ausgabeströme – Standardausgabe und Standardfehler – in Dateien umgeleitet werden, gibt es keine sichtbare Ausgabe im Terminalfenster. Wir kehren zur Eingabeaufforderung der Befehlszeile zurück, als ob nichts passiert wäre.

Lassen Sie uns den Inhalt jeder Datei überprüfen:

 cat-capture.txt

 cat error.txt 

Umleitung von stdout und stderr in dieselbe Datei

Das ist nett, wir haben jeden der Standardausgabeströme in eine eigene dedizierte Datei geleitet. Die einzige andere Kombination, die wir machen können, ist, sowohl stdout als auch stderr an dieselbe Datei zu senden.

Dies erreichen wir mit folgendem Befehl:

 ./error.sh > capture.txt 2>&1

Lassen Sie uns das aufschlüsseln.

• ./error.sh : Startet die Skriptdatei error.sh.
• > capture.txt : Leitet den stdout -Stream in die Datei capture.txt um. > ist eine Abkürzung für 1> .
• 2>&1 : Dies verwendet die &> Umleitungsanweisung. Mit dieser Anweisung können Sie der Shell mitteilen, dass ein Stream dasselbe Ziel erreichen soll wie ein anderer Stream. In diesem Fall sagen wir „Stream 2, stderr , an dasselbe Ziel umleiten, an das Stream 1, stdout , umgeleitet wird.“

Es gibt keine sichtbare Ausgabe. Das ist ermutigend.

Lassen Sie uns die Datei capture.txt überprüfen und sehen, was darin enthalten ist.

 cat-capture.txt 

Sowohl der stdout als auch der stderr -Stream wurden zu einer einzigen Zieldatei umgeleitet.

Um die Ausgabe eines Streams umzuleiten und stillschweigend wegzuwerfen, leiten Sie die Ausgabe an /dev/null weiter.

Umleitung innerhalb eines Skripts erkennen

Wir haben besprochen, wie ein Befehl erkennen kann, ob einer der Streams umgeleitet wird, und sein Verhalten entsprechend ändern kann. Können wir dies in unseren eigenen Skripten erreichen? Ja wir können. Und es ist eine sehr einfach zu verstehende und anzuwendende Technik.

Geben Sie den folgenden Text in einen Editor ein und speichern Sie ihn als input.sh.

 #!/bin/bash

wenn [ -t 0 ]; dann

  echo stdin kommt von der tastatur
 
anders

  echo stdin aus einer Pipe oder einer Datei
 
fi

Verwenden Sie den folgenden Befehl, um es ausführbar zu machen:

 chmod +x input.sh

Der Clou ist der Test in den eckigen Klammern. Die Option -t (Terminal) gibt wahr (0) zurück, wenn die Datei, die dem Dateideskriptor zugeordnet ist, im Terminalfenster beendet wird. Wir haben den Dateideskriptor 0 als Argument für den Test verwendet, der stdin darstellt.

Wenn stdin mit einem Terminalfenster verbunden ist, wird sich der Test als wahr erweisen. Wenn stdin mit einer Datei oder einer Pipe verbunden ist, schlägt der Test fehl.

Wir können jede geeignete Textdatei verwenden, um Eingaben für das Skript zu generieren. Hier verwenden wir eine namens dummy.txt.

 ./input.sh < Dummy.txt 

Die Ausgabe zeigt, dass das Skript erkennt, dass die Eingabe nicht von einer Tastatur kommt, sondern aus einer Datei. Wenn Sie möchten, können Sie das Verhalten Ihres Skripts entsprechend ändern.

Das war mit einer Dateiumleitung, versuchen wir es mit einer Pipe.

 Katzenattrappe.txt | ./input.sh 

Das Skript erkennt, dass seine Eingabe dorthin geleitet wird. Oder genauer gesagt, es erkennt wieder einmal, dass der stdin Stream nicht mit einem Terminalfenster verbunden ist.

Lassen Sie uns das Skript ohne Pipes oder Redirects ausführen.

 ./input.sh 

Der stdin Stream wird mit dem Terminalfenster verbunden, und das Skript meldet dies entsprechend.

Um dasselbe mit dem Ausgabestream zu überprüfen, benötigen wir ein neues Skript. Geben Sie Folgendes in einen Editor ein und speichern Sie es als output.sh.

 #!/bin/bash

wenn [-t 1 ]; dann

echo stdout geht zum Terminalfenster
 
anders

echo stdout wird umgeleitet oder weitergeleitet
 
fi

Verwenden Sie den folgenden Befehl, um es ausführbar zu machen:

 chmod +x input.sh

Die einzige wesentliche Änderung an diesem Skript findet sich im Test in den eckigen Klammern. Wir verwenden die Ziffer 1, um den Dateideskriptor für stdout darzustellen.

Probieren wir es aus. Wir werden die Ausgabe durch cat .

 ./Ausgabe | Katze 

Das Skript erkennt, dass seine Ausgabe nicht direkt an ein Terminalfenster geht.

Wir können das Skript auch testen, indem wir die Ausgabe in eine Datei umleiten.

 ./output.sh > capture.txt 

Es erfolgt keine Ausgabe an das Terminalfenster, wir kehren stillschweigend zur Eingabeaufforderung zurück. Wie wir es erwarten würden.

Wir können in der Datei capture.txt nachsehen, was erfasst wurde. Verwenden Sie dazu den folgenden Befehl.

 cat capture.sh 

Auch hier erkennt der einfache Test in unserem Skript, dass der stdout -Stream nicht direkt an ein Terminalfenster gesendet wird.

Wenn wir das Skript ohne Pipes oder Umleitungen ausführen, sollte es erkennen, dass stdout direkt an das Terminalfenster gesendet wird.

 ./output.sh 

Und genau das sehen wir.

Bewusstseinsströme

Wenn Sie wissen, wie Sie feststellen können, ob Ihre Skripts mit dem Terminalfenster oder einer Pipe verbunden sind oder umgeleitet werden, können Sie ihr Verhalten entsprechend anpassen.

Protokollierung und Diagnoseausgabe können mehr oder weniger detailliert sein, je nachdem, ob es auf den Bildschirm oder in eine Datei geht. Fehlermeldungen können in einer anderen Datei als die normale Programmausgabe protokolliert werden.

Wie so oft bringt mehr Wissen mehr Möglichkeiten.