Umleitung von STDIN, STDOUT, STDERR nach /dev/null in C
Lesezeit: 2 Minuten
Paul
In Stevens’ UNIX Network Programming erwähnt er die Umleitung von stdin, stdout und stderr, was beim Einrichten eines Daemons benötigt wird. Er tut es mit dem folgenden C-Code
/* redirect stdin, stdout, and stderr to /dev/null */
open("/dev/null", O_RDONLY);
open("/dev/null", O_RDWR);
open("/dev/null", O_RDWR);
Ich bin verwirrt, woher diese drei „wissen“, dass sie die drei std* umleiten. Zumal die letzten beiden Befehle gleich sind. Könnte jemand erklären oder mich in die richtige Richtung weisen?
Tsch. Es ist gefährlich, es so zu machen. Verwenden Sie immer dup2().
– Ignacio Vazquez-Abrams
24. November 2010 um 3:24 Uhr
Es ist nicht gefährlich, wenn Ihr Prozess Single-Threaded ist und Sie die alte stdin/out/err bereits geschlossen haben.
– R.. GitHub HÖR AUF, EIS ZU HELFEN
24. November 2010 um 3:28 Uhr
Diese Antwort könnte hilfreich sein: stackoverflow.com/a/4973065/207753
– SlappyTheFish
21. Oktober 2013 um 11:05 Uhr
Bitte tun Sie dies auf keinen Fall. Ich weiß, dass es sich um eine 5 Jahre alte Frage handelt, aber bereits 2003 wurde darauf hingewiesen, dass das Umleiten von stdin, stdout und stderr nach /dev/null dem Systemadministrator viel Kopfzerbrechen bereitet. cloud9.hedgee.com./scribbles/daemon#logging
– Yufan Lou
3. Mai 2016 um 16:16 Uhr
Vermutlich wurden die Dateideskriptoren 0, 1 und 2 bereits geschlossen, wenn dieser Code ausgeführt wird, und es gibt keine anderen Threads, die neue Dateideskriptoren zuweisen könnten. In diesem Fall seit open erforderlich ist, um immer die niedrigste verfügbare Dateideskriptornummer zuzuweisen, ergeben diese drei Aufrufe zum Öffnen die Dateideskriptoren 0, 1 und 2, sofern sie nicht fehlschlagen.
Jeden Grund, den er wählte O_RDWR Anstatt von O_WRONLY?
– Matt Tischler
24. November 2010 um 3:23 Uhr
Weil die Reihenfolge der Dateideskriptoren stdin, stdout, stderr ist. Die Standardeingabe ist natürlich schreibgeschützt.
– sležica
24. November 2010 um 3:24 Uhr
Sicherlich könnten stdout und stderr geöffnet werden O_WRONLYaber ich glaube nicht, dass es wirklich wichtig ist …
– R.. GitHub HÖR AUF, EIS ZU HELFEN
24. November 2010 um 3:29 Uhr
Sie haben Recht, alle Dateideskriptoren wurden vor dem von mir bereitgestellten Code geschlossen. Danke, das macht absolut Sinn.
– Paulus
4. Dezember 2010 um 20:06 Uhr
@R..GitHubSTOPHELPINGICE ein Fall ist still und tut etwas, was Sie nie beabsichtigt hatten, ein anderer Fall gibt einen expliziten Fehler zurück, der Ihnen mitteilt, dass das, was Sie tun, völlig falsch ist. Es spielt offensichtlich eine Rolle, es sei denn, die Softwarequalität spielt keine Rolle.
– Benutzer11877195
3. März um 17:34 Uhr
paxdiablo
Dies liegt daran, dass die Dateideskriptoren 0, 1 und 2 jeweils Eingabe, Ausgabe und Fehler sind und open den ersten verfügbaren Dateideskriptor greift. Beachten Sie, dass dies nur funktioniert, wenn die Dateideskriptoren 0, 1 und 2 nicht bereits verwendet werden.
Und Sie sollten auf die verwendeten Begriffe achten, stdin, stdout und stderr sind eigentlich Dateihandles (FILE*) und nicht Dateideskriptoren, obwohl es eine Korrelation zwischen diesen und den Dateideskriptoren gibt.
10542500cookie-checkUmleitung von STDIN, STDOUT, STDERR nach /dev/null in Cyes
Tsch. Es ist gefährlich, es so zu machen. Verwenden Sie immer
dup2()
.– Ignacio Vazquez-Abrams
24. November 2010 um 3:24 Uhr
Es ist nicht gefährlich, wenn Ihr Prozess Single-Threaded ist und Sie die alte stdin/out/err bereits geschlossen haben.
– R.. GitHub HÖR AUF, EIS ZU HELFEN
24. November 2010 um 3:28 Uhr
Diese Antwort könnte hilfreich sein: stackoverflow.com/a/4973065/207753
– SlappyTheFish
21. Oktober 2013 um 11:05 Uhr
Bitte tun Sie dies auf keinen Fall. Ich weiß, dass es sich um eine 5 Jahre alte Frage handelt, aber bereits 2003 wurde darauf hingewiesen, dass das Umleiten von stdin, stdout und stderr nach /dev/null dem Systemadministrator viel Kopfzerbrechen bereitet. cloud9.hedgee.com./scribbles/daemon#logging
– Yufan Lou
3. Mai 2016 um 16:16 Uhr