Как перенаправить stdout, stderr обратно в /dev/tty

Я просто ssh-ed на какой-то удаленный сервер и нашел, что stdout и stderr из всех команд / процессов, которые я пытаюсь запустить в bash, перенаправляется куда-то. Итак, у меня есть следующие вопросы

как определить:

1) какой файл stdout, stderr перенаправляется ли beeing в Linux?

и

2) и как перенаправить по умолчанию stdout и stderr вернуться к /dev / tty?

спасибо заранее.

11
bash linux stderr stdout tty

4 ответов

команда, которая должна сделать буквально то, что вы просили в (2)

exec >/dev/tty 2>&1

но я подозреваю, что ваш анализ проблемы неправильно. Было бы полезно увидеть результат ssh -v ... (где ... - это любые аргументы, которые вы ввели в свой оригинал ssh command).

10

команды:

ls -l /proc/$$/fd/{1,2}

покажет вам, какие файлы открыты как stdout (файловый дескриптор 1) и stderr (файловый дескриптор 2).

8

это можно сделать только в том случае, если ваша тоска оболочка запускается с трубы до tee команда с другой консолью в качестве параметра.

позвольте мне объяснить.

если вы входите в /dev/tty1 и кто-то еще входит в /dev/tty2. Если вы запустите свою оболочку (bash), выполнив команду, все STDOUT/STDERR будут перенаправлены/скопированы в другую оболочку (/dev/tty2 в данном случае).

bash 2>&1 | tee /dev/tty2

так, кто-то сидит в /dev/tty2 увидите все ваша деятельность.

если кто-то входит в оболочку /bin/bash 2>&1 | tee /dev/tty2 вместо /bin/bash это произойдет каждый раз, когда он входит в систему. Но я не уверен, что login shell можно установить таким образом.

если кто-то перенаправляет весь вывод вашей оболочки таким образом, вы можете проверить его, просто проверив, есть ли tee работает в фоновом режиме. 

ps ax | grep tee

это выведет что-то вроде

tee /dev/tty2
1

ответ на ваш первый вопрос можно найти в /proc/self/fd. Он содержит символические ссылки на файлы (или другие вещи, трубы, сокеты и т. д.), к которым подключен ваш экземпляр bash.

root@mammon:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15529/fd/
root@mammon:~# ls -l /proc/self/fd < /dev/null
total 0
lr-x------ 1 root root 64 May 21 02:18 0 -> /dev/null
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15536/fd/
root@mammon:~# ls -l /proc/self/fd | cat
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
l-wx------ 1 root root 64 May 21 02:18 1 -> pipe:[497711]
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15537/fd/
root@mammon:~#

в первом примере вы можете увидеть первые 3 дескриптора файлов (которые являются стандартным выходом, входом и ошибкой, соответственно), все указывают на мой псевдо-терминал /dev/pts/3. Во втором примере я перенаправил ввод на /dev/null, поэтому стандартный дескриптор входного файла указывает на /dev/null. И в последнем примере я отправил вывод ls to cat через канал, и стандартный дескриптор входного файла отражает это. Насколько я знаю, нет способа найти, какой процесс имеет другой конец трубы. Во всех примерах есть четвертый файловый дескриптор, представляющий дескриптор, который ls имеет значение /proc/self/fd. В этом случае он говорит /proc/15537, потому что /proc/self на самом деле является символической ссылкой на /proc/pid здесь pid является PID процесса доступа /proc/self.

1