Jak przekierować stdout, stderr z powrotem do/dev/tty

Question

Po prostu przeszedłem do jakiegoś zdalnego serwera i odkryłem, że stdout i stderr wszystkich poleceń/procesów, które próbuję uruchomić w bashu, jest przekierowane gdzieś. Tak, mam następujące pytania

Jak wykryć:

1) Który plik stdout, stderr jest beeing przekierowane w Linuksie?

i

2) A jak przekierować domyślnie stdout i stderr powrotem do/dev/tty?

Z góry dziękuję.

Answer 1

Polecenie to powinno robić dosłownie co prosiłeś w (2) jest

exec >/dev/tty 2>&1 

Ale podejrzewam, że analiza problemu jest nieprawidłowe. Przydałoby się zobaczyć wyjście ssh -v ... (gdzie ... jest dowolnymi argumentami wpisanymi w oryginalnym poleceniu ssh).

Answer 2

Można to zrobić tylko, jeśli twoja tęsknota za powłoką jest uruchamiana z poleceniem tee z inną konsolą jako parametrem.

Pozwól mi wyjaśnić.

Jeśli logujesz się /dev/tty1, a inna osoba loguje się /dev/tty2. Jeśli uruchomisz powłokę (bash), wykonując następujące polecenie, wszystkie STDOUT/STDERR zostaną przekierowane/skopiowane do innej powłoki (w tym przypadku /dev/tty2).

bash 2>&1 | tee /dev/tty2 

Tak więc ktoś siedzący w /dev/tty2 zobaczy całą Twoją aktywność.

Jeśli ktoś zaloguje się do powłoki to /bin/bash 2>&1 | tee /dev/tty2 zamiast /bin/bash Stanie się to za każdym razem, gdy się loguje. Ale nie jestem pewien, czy powłoka logowania może zostać ustawiona w ten sposób.

Jeśli ktoś przekieruje wszystkie wyjścia twojej powłoki w ten sposób, możesz to sprawdzić, sprawdzając, czy w tle działa jakaś tee.

ps ax | grep tee 

Wyjście to będzie coś

tee /dev/tty2 

Answer 3

Polecenie:

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

was, które pliki są otwarte jak (deskryptor pliku 1) stdout i stderr pokazać (deskryptor pliku 2) .

Answer 4

Odpowiedź na pierwsze pytanie można znaleźć pod numerem /proc/self/fd. Zawiera dowiązania symboliczne do plików (lub innych rzeczy, potoków, gniazd itp.), Z którymi jest połączona twoja instancja 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:~# 

W pierwszym przykładzie, można zobaczyć pierwsze 3 deskryptory plików (które są standardowe wyjście, wejście i błędów, odpowiednio), wskazują na moim pseudo-terminal /dev/pts/3. W drugim przykładzie przekierowałem dane wejściowe na /dev/null, więc standardowy deskryptor pliku wejściowego wskazuje na /dev/null. I w ostatnim przykładzie wysłałem wyjście ls do cat przez potok, a standardowy deskryptor pliku wejściowego to odzwierciedla. O ile mi wiadomo, nie ma sposobu, aby dowiedzieć się, który proces ma drugi koniec rury. We wszystkich przykładach znajduje się czwarty deskryptor pliku, który reprezentuje uchwyt, który ls ma do czytania /proc/self/fd. W tym przypadku jest napisane: /proc/15537, ponieważ /proc/self jest w rzeczywistości dowiązaniem symbolicznym do /proc/pid, gdzie pid jest identyfikatorem PID procesu uzyskującego dostęp do /proc/self.