In bash können Sie tun:
echo test >&1 (Weiterleitung an stdout, obwohl es bereits dorthin geht) echo test >&2 (Weiterleitung an stderr) echo test >&0 (Weiterleitung an stdin) Wenn ich das letzte mache, druckt mein Terminal immer noch test , wie es bei den anderen beiden der Fall wäre, aber es ist schwer zu wissen warum. Also zuerst, warum funktioniert das überhaupt? Zweitens, gibt es einen guten Nutzen für die Umleitung auf Stdin?
Um genauer zu sein, was >&0 macht, dupliziert den Dateideskriptor 0 als Dateideskriptor 1. Wenn das Programm stdin nur zum Lesen geöffnet ist, dann wird es, wenn Ihr Programm versucht, in stdout (Dateideskriptor 1) zu schreiben einen Fehler bekommen, weil der Dateideskriptor 1 auch nur zum Lesen geöffnet ist.
Sie können dies demonstrieren, indem Sie ein kleines Shell-Skript schreiben, das seine eigenen Dateideskriptoren prüft:
10156115.sh:
%Vor%Und dann rufen Sie es mit identifizierbaren stdin, stdout und stderr auf:
%Vor% Das Ergebnis ist, dass Sie in stderr Folgendes erhalten:
Standardmäßig sind jedoch alle drei Terminals: (Ausgabe vereinfacht)
%Vor% In der Regel sind alle drei tatsächlich read + write, also hat die >&0 redirect überhaupt keinen Effekt, wenn sie von einer normalen Shell alleine verwendet wird.
Gibt es irgendwelche Verwendungen dafür?
Es gibt keine gebräuchliche Verwendung, aber Sie können es als einen schmutzigen Hack verwenden, um eine Möglichkeit zum Drucken auf dem Terminal zu erhalten, wenn Ihre Skriptumleitungen stdout und stderr aufrufen, und aus welchen Gründen auch immer Das kann ich nicht ändern:
Aber ich würde das nicht empfehlen.
Aus historischen Gründen sind die Standard-Dateideskriptoren auf einem Terminal lesend / schreibend anstatt schreibgeschützt (speziell wird es einmal geöffnet und dup() ed an die anderen). Dies ist gelegentlich nützlich für Programme, die piped Eingaben vornehmen möchten, aber auch Eingaben vom Benutzer lesen (aus stdout oder häufiger stderr ), obwohl die Verwendung von /dev/tty in diesem Fall zuverlässiger ist. Einige Systeme wenden dies auf mehr als nur ttys an: Die * BSDs öffnen bypersonal Socketpairs ("Pipes"), und einige Systemprogramme (ich erinnere mich, dass ufsdump ein Beispiel ist) hängen davon ab.
Die Umleitung von zu stdin (dh, es ist nur zum Schreiben geöffnet) ist im Allgemeinen nicht sinnvoll, da die meisten Programme erwarten, dass es zum Lesen geöffnet ist (oder manchmal wie oben beschrieben) ).