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

Question

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

Как обнаружить:

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

и

2) И как перенаправлять по умолчанию stdout и stderr обратно в/разработчика/TTY?

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

Answer 1

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

exec >/dev/tty 2>&1 

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

Answer 2

Это может быть сделано только в том случае, если ваша тоскающая оболочка запускается с помощью трубы в команду 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 Это будет происходить каждый раз, когда он войдет в систему. Но я не уверен, что логическая оболочка может быть установлена ​​таким образом.

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

ps ax | grep tee 

Этот выход будет что-то вроде

tee /dev/tty2 

Answer 3

Команда:

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

покажет вам, какие файлы открыты в стандартный вывод (файловый дескриптор 1) и поток ошибок (дескриптор файла 2) ,

Answer 4

Ответ на ваш первый вопрос можно найти в /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 в cat через трубку, и это отражает стандартный дескриптор входного файла. Насколько я знаю, нет способа найти, какой процесс имеет другой конец трубы. Во всех примерах есть четвертый файловый дескриптор, представляющий дескриптор, который ls имеет для чтения /proc/self/fd. В этом случае он говорит /proc/15537, потому что /proc/self на самом деле является символической ссылкой на /proc/pid, где pid является PID процесса, получающего доступ к /proc/self.