Przywracanie danych wyjściowych do terminala po wydaniu „exec &> filename”

Próbuję wykonać następujące czynności:

exec &>filename

Po tym nie widzę nic, w tym tego, co napisałem, w porządku.

I gorączkowo próbować, exec 1>&1i exec 2>&2, ale nic się nie dzieje.

Teraz, bez zabijania powłoki, w jaki sposób mogę odzyskać dane wyjściowe przekierowane odpowiednio na stdout i błąd przekierowany odpowiednio do stderr? Czy deskryptory plików to jedyny sposób odwoływania się do standardowych [wejściowych | wyjściowych] put i stderr?

Po uruchomieniu exec &>filenamestandardowe wyjście i standardowy błąd powłoki trafiają do filename. Standardowe wejście to z definicji deskryptor pliku 0, a standardowe wyjście to fd 1, a standardowy błąd to fd 2.

Deskryptor pliku nie jest ani przekierowany, ani nie przekierowany: zawsze gdzieś idzie (zakładając, że proces ma otwarty ten deskryptor). Przekierowanie deskryptora pliku oznacza zmianę kierunku. Kiedy exec &>filenamebiegałeś, stdout i stderr były wcześniej podłączone do terminala i łączyły się z filename.

Nie zawsze jest sposób, aby zapoznać się z bieżącym terminalu: /dev/tty. Gdy proces otwiera ten plik, zawsze oznacza terminal kontrolny procesu , w zależności od tego, co to jest. Więc jeśli chcesz odzyskać oryginalny stdout i stderr tej powłoki, możesz to zrobić, ponieważ plik, z którym byli połączeni, wciąż istnieje.

exec &>/dev/tty

Chcesz

exec &>$(tty)

To, co robisz w swoim pytaniu, to replikacja w stdout i stderr oryginalnego stdout i stderr, które zostały już przekierowane do pliku.

Jak wyjaśnia odpowiedź Gillesa, ttyzwróci urządzenie końcowe bieżącego terminala. To tutaj domyślnie przychodzą / przechodzą trzy standardowe deskryptory plików w powłoce logowania. Tak więc powyższe oświadczenie wykorzystuje ttyprzekierowanie stdout i stderr z powrotem do urządzenia końcowego, tak jak poprzednio.

Jeśli obawiasz się o przenośność (zgodnie z komentarzem do odpowiedzi Gillesa), obie metody ( narzędzie tty i /dev/ttyplik ) są w standardzie POSIX.

Skopiowano dosłownie komentarz Gillesa:

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