How to reroute stdout, stderr back to /dev/tty
Question
I just ssh-ed to some remote server and found that stdout
and stderr
of all commands/processes I am trying to run in bash is redirected to somewhere.
So, I got following questions
How to detect:
1) Which file stdout
, stderr
is beeing rerouted in Linux?
and
2) And how reroute by default stdout
and stderr
back to /dev/tty?
Thank you in advance.
Solution
A command that should do literally what you asked for in (2) is
exec >/dev/tty 2>&1
But I suspect that your analysis of the problem is incorrect. It would be useful to see the output of ssh -v ...
(where ...
is whatever arguments you typed in your original ssh
command).
OTHER TIPS
The command:
ls -l /proc/$$/fd/{1,2}
will show you which files are open as stdout (file descriptor 1) and stderr (file descriptor 2).
It can only be done if your longing shell is started with a pipe to tee
command with another console as a parameter.
Let me explain.
If you are logging in /dev/tty1
and someone else is logging in /dev/tty2
. If you start your shell (bash) by following command all the STDOUT/STDERR will be rerouted/copied to another shell (/dev/tty2
in this case).
bash 2>&1 | tee /dev/tty2
So, someone sitting in /dev/tty2
will see all of your activity.
If someone logins shell is /bin/bash 2>&1 | tee /dev/tty2
instead of /bin/bash
It'll happen every time he logs in. But I am not sure login shell can be set that way.
If someone reroutes all the output of your shell this way you can check it just by checking if any tee
is running in background.
ps ax | grep tee
This will output something like
tee /dev/tty2
An answer to your first question could be found in /proc/self/fd
. It contains symlinks to the files (or other things, pipes, sockets, etc) that your bash instance is connected to.
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:~#
In the first example, you can see the first 3 file descriptors (which are the standard output, input, and error, respectively) all point to my pseudo-terminal /dev/pts/3
. In the second example I've redirected the input to /dev/null
, so the standard input file descriptor points to /dev/null
. And in the final example I've sent the output of ls
to cat
through a pipe, and the standard input file descriptor reflects this. As far as I know there is no way to find which process has the other end of the pipe. In all examples there is the fourth file descriptor that represents the handle that ls
has for reading /proc/self/fd
. In this case it says /proc/15537
because /proc/self
is in fact a symlink to /proc/pid
where pid
is the PID of the process accessing /proc/self
.