Відновлення виводу в термінал після видачі "exec &> filename"

Я намагаюся виконати наступне:

exec &>filename

Після цього я не в змозі побачити нічого, включаючи те, що я набрав, добре.

Я несамовито намагаюся, exec 1>&1і exec 2>&2, але нічого не відбувається.

Тепер, не вбиваючи оболонку, як мені повернути вихід, перенаправлений на stdout та помилку, переадресовану відповідно до stderr? Чи є дескриптори файлів єдиним способом посилання на стандартні [in | out] put та stderr?

Після запуску exec &>filenameпереходять до стандартного виводу та стандартної помилки оболонки filename. Стандартний вхід - це дескриптор файлу 0 за визначенням, а стандартний вихід - fd 1, а стандартна помилка - fd 2.

Дескриптор файлу не є ні перенаправленим, ні не перенаправленим: він завжди кудись іде (якщо припустимо, що цей дескриптор відкритий). Перенаправити дескриптор файлу означає змінити, куди він йде. Коли ви бігли exec &>filename, stdout та stderr раніше були підключені до терміналу і стали підключені до нього filename.

Існує завжди спосіб звернення до поточного терміналу: /dev/tty. Коли процес відкриває цей файл, він завжди означає керуючий термінал , залежно від того, який він є. Тож якщо ви хочете повернути оригінальний stdout і оболонку цього оболонки, ви можете це зробити, оскільки файл, до якого вони були підключені, все ще є.

exec &>/dev/tty

Ти хочеш

exec &>$(tty)

Що ви робите у своєму запитанні - це реплікація в stdout та stderr оригінальної stdout та stderr, які вже були перенаправлені до файлу.

Як пояснюється у відповіді Жилла, ttyповернеться термінальний пристрій поточного терміналу. Ось де три стандартних дескриптора файлів надходять / збираються за замовчуванням у оболонці для входу. Отже, наведене вище твердження використовує ttyдля перенаправлення stdout та stderr назад до термінального пристрою, як це було раніше.

Якщо вас турбує портативність (згідно з вашим коментарем до відповіді Гілла), обидва способи ( утиліта tty та /dev/ttyфайл ) відповідають стандарту POSIX.

Скопійовано дослівно з коментаря Жиля:

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