Wiederherstellung der Ausgabe auf dem Terminal nach der Ausgabe von "exec &> Dateiname"

Ich versuche folgendes auszuführen:

exec &>filename

Danach kann ich nichts mehr sehen, auch nicht das, was ich eingegeben habe.

Ich versuche verzweifelt, exec 1>&1und exec 2>&2, aber nichts passiert.

Wie kann ich nun, ohne die Shell zu beenden, die Ausgabe an die Standardausgabe und den Fehler an die Standardausgabe zurückgeben? Sind die Dateideskriptoren die einzige Möglichkeit, auf standard [in | out] put und stderr zu verweisen?

io-redirection

— user917279
quelle

Hmm ... warum leiten Sie dann das stderr / stdout Ihrer interaktiven Shell um? Dieses execKonstrukt wird normalerweise in Skripten verwendet, die in einer Subshell ausgeführt werden, um ihre Ausgabe zB in eine Datei umzuleiten. Ich sehe keine Verwendung für eine interaktive Sitzung.

— Martin von Wittich

@MartinvonWittich Ich stimme der Aussage zu exec. Genau. Ich bin nur ein Kind

— herumspielen

Antworten:

Nachdem Sie ausgeführt haben exec &>filename, werden die Standardausgabe und der Standardfehler der Shell an weitergeleitet filename. Die Standardeingabe ist per Definition der Dateideskriptor 0, die Standardausgabe ist fd 1 und der Standardfehler ist fd 2.

Ein Dateideskriptor wird weder umgeleitet noch nicht umgeleitet: Er wird immer an einen beliebigen Ort verschoben (vorausgesetzt, der Prozess hat diesen Deskriptor geöffnet). Ein Dateideskriptor umzuleiten bedeutet zu ändern, wo er hingeht. Als Sie rannten exec &>filename, waren stdout und stderr zuvor mit dem Terminal verbunden und wurden mit verbunden filename.

Es gibt immer einen Weg , um den Stromanschluss zu beziehen: /dev/tty. Wenn ein Prozess diese Datei öffnet, bedeutet dies immer das steuernde Terminal des Prozesses , unabhängig davon, um welches es sich handelt. Wenn Sie also das ursprüngliche stdout und stderr der Shell wiederherstellen möchten, können Sie dies tun, da die Datei, mit der sie verbunden waren, noch vorhanden ist.

exec &>/dev/tty

— Gilles 'SO - hör auf böse zu sein'
quelle

wie @Joseph R. antwortete $ (tty) zeigt mir / dev / pty0, aber Ihr Befehl funktioniert auch, welcher ist portabler für Unix-Flavors? Vielen Dank für die klarere Antwort.

— user917279

@ user917279 Sie sind im Sinne der Arbeit an verschiedenen Unix-Varianten gleichermaßen portabel. /dev/ttyFunktioniert in Fällen, in denen $(tty)dies nicht der Fall ist: /dev/ttyFunktioniert, solange der Prozess über ein steuerndes Terminal verfügt (was das Beste ist, was Sie hoffen können, da noch eine Verbindung zwischen dem Prozess und dem Terminal bestehen muss), während $(tty)das Terminal weiterhin geöffnet sein muss bei Standardeingabe.

— Gilles 'SO- hör auf böse zu sein'

Sie wollen

exec &>$(tty)

Was Sie in Ihrer Frage tun, ist, in stdout und stderr das ursprüngliche stdout und stderr zu replizieren, die bereits in die Datei umgeleitet wurden.

Wie Gilles 'Antwort erklärt, ttywird das Endgerät des aktuellen Endgeräts zurückgegeben. Hierher kommen / gehen standardmäßig die drei Standard-Dateideskriptoren in einer Login-Shell. Die obige Anweisung verwendet also tty, um stdout und stderr wie bisher zurück zum Endgerät zu leiten.

Wenn Sie sich Gedanken über die Portabilität machen (wie in Ihrem Kommentar zu Gilles 'Antwort angegeben), sind beide Methoden (das Dienstprogramm tty und die /dev/ttyDatei ) im POSIX-Standard enthalten.

Wortwörtlich aus Gilles 'Kommentar übernommen:

There's an advantage to /dev/tty: it works even after exec <somefile, 
whereas $(tty) would complain “not a tty”

— Joseph R.
quelle

Es klappt! Vielen Dank. echo $ (tty) ergibt / dev / pty0 (in cygwin), in welcher Beziehung steht es zu stdin, stdout und was passiert mit der obigen Anweisung? Bitte lassen Sie es mich wissen, wenn ich dies als separate Frage stellen muss.

— user917279

@ user917279 Antwort aktualisiert.

— Joseph R.

Vielen Dank, Joseph. Ich habe diese Frage gestellt, bevor ich mir Giles 'Antwort ansah. Vielen Dank. Bitte erlauben Sie mir, Giles Antwort als akzeptiert zu markieren, da dies selbst dumme Menschen wie mich dazu brachte, richtig zu verstehen.

— user917279

Das hat den Vorteil, dass /dev/ttyes auch nachher funktioniert exec <somefile, während $(tty)sich "kein bisschen" beschwert.

— Gilles 'SO- hör auf böse zu sein'

@ Gilles Danke für den charakteristisch aufschlussreichen Kommentar :)

— Joseph R.