stdin, stdout und stderr sind drei Datenströme, die beim Starten eines Linux-Befehls erstellt werden. Sie können sie verwenden, um festzustellen, ob Ihre Skripte weitergeleitet oder umgeleitet werden. Wir zeigen Ihnen wie.
Inhaltsverzeichnis
Streams verbinden zwei Punkte
Sobald Sie anfangen, Linux und Unix-ähnliche Betriebssysteme kennenzulernen, werden Sie auf die Begriffe stdin, stdout und stederr stoßen. Diese sind drei Standardstreams die erstellt werden, wenn ein Linux-Befehl ausgeführt wird. In der Computertechnik 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. Welchen Linux-Befehl Sie auch immer verwenden, stellt ein Ende jedes Streams bereit. Das andere Ende wird von der Shell bestimmt, die den Befehl gestartet hat. Dieses Ende wird entsprechend der Befehlszeile, die den Befehl gestartet hat, 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 Stream stdout (standard out) geliefert. Fehlermeldungen des Befehls werden über den Stream stderr (Standardfehler) gesendet.
Sie können also sehen, dass es zwei Ausgabestreams, stdout und stderr, und einen Eingabestream, stdin, gibt. Da Fehlermeldungen und normale Ausgaben jeweils über einen eigenen Kanal zum Terminalfenster führen, 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 verarbeiten, 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. Immer wenn eine Aktion für eine Datei ausgeführt werden muss, der Dateideskriptor wird verwendet, um die Datei zu identifizieren.
Diese Werte werden immer für stdin, stdout und stderr verwendet:
0: stdin
1: Standard
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 vermitteln. Bei der Grammatik wird uns beispielsweise gesagt, dass die Regel „I vor E, außer nach C“ lautet. Aber eigentlich, da sind weitere Ausnahmen von dieser Regel als es Fälle gibt, die ihm gehorchen.
In ähnlicher Weise ist es praktisch, wenn man über stdin, stdout und stderr spricht, das akzeptierte Axiom herauszustreichen, dass ein Prozess weder weiß noch sich darum kümmert, wo seine drei Standardströme enden. Sollte sich ein Prozess darum kümmern, ob seine Ausgabe an das Terminal geht oder in eine Datei umgeleitet wird? Kann es sogar 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 entscheiden sollte – 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 sehen. Probieren Sie diese beiden Befehle aus:
ls
ls | cat
Der Befehl ls verhält sich anders, wenn seine Ausgabe (stdout) in einen anderen Befehl geleitet wird. Es ist ls, das auf eine einspaltige Ausgabe umschaltet, es ist keine Konvertierung, die von cat durchgeführt wird. Und ls macht dasselbe, wenn seine Ausgabe umgeleitet wird:
ls > capture.txt
Umleitung von stdout und stderr
Es ist von Vorteil, wenn 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. Sie können bei Bedarf auf die auftretenden Fehler 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 "About to try to access a file that doesn't exist" cat bad-filename.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. Dadurch wird eine Fehlermeldung generiert, 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 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 Standardausgabestream Sie umleiten möchten.
Um stdout explizit umzuleiten, verwenden Sie diese Umleitungsanweisung:
1>
Um stderr explizit umzuleiten, verwenden Sie diese Umleitungsanweisung:
2>
Versuchen wir unseren Test noch einmal, und diesmal verwenden wir 2>:
./error.sh 2> capture.txt
Die stderr-Nachricht befindet sich wie erwartet in der Datei capture.txt.
Umleitung von stdout und stderr
Wenn wir entweder stdout oder stderr unabhängig voneinander in eine Datei umleiten können, sollten wir beide gleichzeitig in 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
Lassen Sie uns den Inhalt jeder Datei überprüfen:
cat capture.txt
cat error.txt
Umleiten von stdout und stderr in dieselbe Datei
Das ist nett, wir haben jeden der Standardausgabestreams in eine eigene dedizierte Datei. Die einzige andere Kombination, die wir tun können, besteht darin, sowohl stdout als auch stderr an dieselbe Datei zu senden.
Dies können wir mit dem folgenden Befehl erreichen:
./error.sh > capture.txt 2>&1
Lass uns das aufschlüsseln.
./error.sh: Startet die Skriptdatei error.sh.
> capture.txt: Leitet den stdout-Stream in die Datei capture.txt um. > steht für 1>.
2>&1: Dies verwendet die &> Umleitungsanweisung. Mit dieser Anweisung können Sie der Shell mitteilen, dass ein Stream zum gleichen Ziel wie ein anderer Stream gelangen soll. In diesem Fall sagen wir: „Umleiten von Stream 2, stderr, an dasselbe Ziel, an das Stream 1, stdout umgeleitet wird.“
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 in eine einzelne Zieldatei umgeleitet.
Um die Ausgabe eines Streams umzuleiten und stillschweigend zu verwerfen, leiten Sie die Ausgabe an /dev/null.
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 if [ -t 0 ]; then echo stdin coming from keyboard else echo stdin coming from a pipe or a file fi
Verwenden Sie den folgenden Befehl, um es ausführbar zu machen:
chmod +x input.sh
Der clevere Teil ist der innerhalb der eckigen Klammern testen. Die Option -t (Terminal) gibt true (0) zurück, wenn die Datei mit dem Dateideskriptor verknüpft ist endet im Terminalfenster. 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 beliebige Textdatei verwenden, um Eingaben für das Skript zu generieren. Hier verwenden wir eine namens dummy.txt.
./input.sh
The output shows that the script recognizes that the input isn’t coming from a keyboard, it is coming from a file. If you chose to, you could vary your script’s behavior accordingly.
That was with a file redirection, let’s try it with a pipe.
cat dummy.txt | ./input.sh
Das Skript erkennt, dass seine Eingabe über eine Pipe geleitet wird. Genauer gesagt erkennt es einmal mehr, 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 ist 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 if [ -t 1 ]; then echo stdout is going to the terminal window else echo stdout is being redirected or piped fiVerwenden Sie den folgenden Befehl, um es ausführbar zu machen:
chmod +x input.shDie einzige signifikante Änderung an diesem Skript ist im Test in den eckigen Klammern. Wir verwenden die Ziffer 1, um den Dateideskriptor für stdout darzustellen.
Probieren wir es aus. Wir leiten die Ausgabe über cat.
./output | cat
Das Skript erkennt, dass seine Ausgabe nicht direkt in 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 im Terminalfenster, wir kehren still zur Eingabeaufforderung zurück. Wie wir es erwarten würden.
Wir können in die Datei capture.txt schauen, um zu sehen, 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 geliefert wird.
./output.sh
Und genau das sehen wir.
Bewusstseinsströme
Wenn Sie wissen, ob Ihre Skripte mit dem Terminalfenster oder einer Pipe verbunden sind oder umgeleitet werden, können Sie ihr Verhalten entsprechend anpassen.
Protokoll- und Diagnoseausgaben können mehr oder weniger detailliert sein, je nachdem, ob sie auf dem Bildschirm oder in einer Datei ausgegeben werden. Fehlermeldungen können in einer anderen Datei als der normalen Programmausgabe protokolliert werden.
Wie so oft bringt mehr Wissen mehr Möglichkeiten.
