Restauration de la sortie sur le terminal après avoir émis "exec &> filename"

J'essaie d'exécuter ce qui suit:

exec &>filename

Après cela, je ne vois rien, y compris ce que j'ai tapé, d'accord.

J'essaye frénétiquement, exec 1>&1et exec 2>&2, mais rien ne se passe.

Maintenant, sans tuer le shell, comment puis-je récupérer la sortie redirigée vers stdout et l'erreur redirigée vers stderr respectivement? Les descripteurs de fichiers sont-ils le seul moyen de référencer les standards [in | out] put et stderr?

io-redirection

— user917279
source

Hmm ... pourquoi redirigez-vous alors le stderr / stdout de votre shell interactif? Cette execconstruction est généralement utilisée dans les scripts qui s'exécutent dans un sous-shell, pour rediriger leur sortie, par exemple vers un fichier. Je n'en vois pas l'utilité dans une session interactive.

— Martin von Wittich

@MartinvonWittich Je suis d'accord avec la déclaration sur l'exec. Je suis d'accord. Je ne suis qu'un enfant qui

— s'amuse

Réponses:

Après avoir exécuté exec &>filename, la sortie standard et l'erreur standard du shell sont affichées filename. L'entrée standard est le descripteur de fichier 0 par définition, et la sortie standard est fd 1 et l'erreur standard est fd 2.

Un descripteur de fichier n'est ni redirigé ni non redirigé: il va toujours quelque part (en supposant que le processus a ce descripteur ouvert). Rediriger un descripteur de fichier signifie changer où il va. Lorsque vous avez couru exec &>filename, stdout et stderr étaient auparavant connectés au terminal et se sont connectés à filename.

Il y a toujours un moyen de se référer à la borne actuelle: /dev/tty. Lorsqu'un processus ouvre ce fichier, cela signifie toujours le terminal de contrôle du processus , quel qu'il soit. Donc, si vous voulez récupérer la stdout et la stderr d'origine de ce shell, vous pouvez le faire car le fichier auquel ils étaient connectés est toujours là.

exec &>/dev/tty

— Gilles 'SO- arrête d'être méchant'
source

comme @Joseph R. a répondu $ (tty) me montre / dev / pty0, mais votre commande fonctionne aussi, laquelle est plus portable à travers les versions Unix? merci à vous pour la réponse plus claire.

— user917279

@ user917279 Ils sont également portables dans le sens où ils fonctionnent sur différentes versions d'Unix. /dev/ttyfonctionne dans les cas où $(tty)cela ne fonctionne pas: /dev/ttyfonctionne tant que le processus a un terminal de contrôle (ce qui est le meilleur que vous pouvez espérer, car il doit y avoir quelque chose qui relie toujours le processus au terminal), tandis que $(tty)nécessite que le terminal soit toujours ouvert sur entrée standard.

— Gilles 'SO- arrête d'être méchant'

Tu veux

exec &>$(tty)

Ce que vous faites dans votre question est de répliquer dans stdout et stderr les stdout et stderr d'origine qui ont déjà été redirigés vers le fichier.

Comme l'explique la réponse de Gilles, ttyretournera le terminal du terminal actuel. C'est là que les trois descripteurs de fichiers standard viennent / vont par défaut dans un shell de connexion. Ainsi, la déclaration ci-dessus utilise ttypour rediriger stdout et stderr vers le terminal comme avant.

Si vous êtes préoccupé par la portabilité (selon votre commentaire sur la réponse de Gilles), les deux méthodes (l' utilitaire tty et le /dev/ttyfichier ) sont dans la norme POSIX.

Copie textuellement du commentaire de Gilles:

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

— Joseph R.
source

Ça marche! Je vous remercie. echo $ (tty) donne / dev / pty0 (dans cygwin), comment est-il lié à stdin, stdout et que se passe-t-il avec l'instruction ci-dessus? faites-le moi savoir si je dois poser cette question séparément.

— user917279

@ user917279 Réponse mise à jour.

— Joseph R.

Merci Joseph. J'ai posté cette question avant de regarder la réponse de Giles. Merci beaucoup. S'il vous plaît, permettez-moi de marquer la réponse de Giles comme acceptée, car cela a fait comprendre même aux esprits stupides comme le mien.

— user917279

Il y a un avantage à /dev/tty: ça marche même après exec <somefile, alors qu'on $(tty)se plaindrait «pas un tty».

— Gilles 'SO- arrête d'être méchant'

@Gilles Merci pour le commentaire particulièrement éclairant :)

— Joseph R.