I have a raspberry pi with a screen attached to it. It boots up to a login prompt. I have no keyboard and no mouse attached to it and would like to keep it this way. I proceed to login to it via ssh from network, but would like to see the commands that I enter through ssh and their output on the attached screen. Would this be possible?
-
I think you mean that you want to display output in a different terminal, not a different shell, right? Because as I understand there would be no extra shell running on the attached screen, just the output would be displayed there. – Celada Jun 14 '15 at 09:04
-
Would like to see both the output and the input. I probably don't know the difference between a shell and a terminal, so feel free to edit the question. – Euphorbium Jun 14 '15 at 09:14
-
1What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'? – Gilles 'SO- stop being evil' Jun 14 '15 at 13:25
3 Answers
I'm not sure whether there might be a more "direct" solution involving only redirecting inputs and outputs, but I did manage to make something like this work using screen. The idea is to do all your work inside a screen
session and attach twice to the session, once from your working SSH terminal and once from the attached display.
First, you will need to know the name of the terminal for the attached display. I don't have a rPI to test with but I assume the directly attached screen gets mapped to the regular Linux video console, so it's probably going to be /dev/tty1
.
- Make sure
screen
is installed - Log in with SSH
Create a new screen session
screen
Attach to the same screen session from the other terminal.
The way this feature is intended to be used is that you would log in using a local keyboard and type
screen -r -x
(for-r
resume session and-x
multi-attach to an existing session) but in this case you aren't actually logged in to the terminal from which you would like to attach to the session. So we redirect input and output to the intended terminal to "convince" screen that's the terminal we want to attach from. It's hackish, but it worked for me.screen -r -x </dev/tty1 >/dev/tty1 2>&1 & disown
If the name of the terminal for the rPI's video console is not /dev/tty1
but something else, you can find out what it is by connecting a keyboard just for once and logging in locally and typing tty
at the prompt.

- 44,132
Interesting, I also thought of screen -x
or tmux attach
like Celada's solution, but I would prefer setting up init (in /etc/inittab
or /etc/init
or /etc/systemd
) or supervisor to automatically launch a getty-on-screen session on boot.
Working configuration for supervisor:
[program:screen]
command=bash -c 'chvt 9 && TERM=linux exec screen getty tty </dev/tty9 >/dev/tty9 2>&1'
autostart=true
autorestart=true
It automatically switches to /dev/tty9
and launches screen running getty to show login prompt. From other ssh sessions you can run sudo screen -x
to attach to this console sesion, then type Ctrl+AD to detach from the session.
You need root privilege to attach the screen session because it's run by root. You might want to enable screen's multi user mode, but it needs setuid on /usr/bin/screen
which causes some security concerns. Consult screen manual for details.

- 12,326
-
1Thanks for going beyond what I thought of doing to make it more clean and automated :) – Celada Jun 14 '15 at 11:39
-
When I run this and try to attach to a screen session, I get "There is no screen to be attached". I have probably messed up supervisor configuration? – Euphorbium Jun 14 '15 at 13:35
If you have xterm
installed on the pi
it should have included the luit
terminal UTF-8 application - which is a little program which is often used to translate for other types of terminal applications that are not UTF-8 aware. luit
works by allocating a pseudo-terminal - in much the way screen
does but with a lot less overhead.
One thing luit
can do very easily is copy input (or output - which can be different) to some specified file as it arrives. To luit
though (as the terminal master) input means all of your terminal session's output (even possibly including its own stty echo
output) and output means everything it would write to a terminal device after processing all of the output from your terminal session. It does this while also copying its stdin (which must come from a terminal - and so means your keyboard) input to the program which it wraps - such as a shell. I know - pty i/o can be a little weird - but, the point is, it can make for a convenient means of duplicating a terminal session's output to multiple display devices in realtime.
For example:
ssh me@machine -t 'luit -olog /dev/tty2 sh'
I have just run (basically) the above command from my android tablet terminal after switching out of X
to vt2 with CTRL+ALT+F2 on my desktop computer to a new login
prompt. The android terminal prompted me for my password in the usual way, and then I was in my shell on the tablet and everything written to my tablet's terminal (prompts, my input, cat file
, etc) was also displayed on my desktop screen. Each key I typed (or touched or whatever) on the tablet was echoed instantly to the desktop vt2.
For this to work, if your tty
spawning process (usually a getty
or similar) creates the terminal devices with some level of permission that your user account cannot meet by default, you will need to alter that. It can be as simple as:
chown me /dev/tty[num]
...if you want it to be. On my system my user account is a member of the tty
group - and so this is not an issue. I believe that on most linux distributions putting a user account in the tty
group should be enough to make it just work.
ls -l /dev/tty2
crw--w---- 1 root tty 4, 2 Jun 14 05:14 /dev/tty2
...as you can see, it is a root-owned device file, but is designated to the tty
group.
In any case, running the above luit
command might be all you ever need. More complex - and possibly desirable - solutions might be had w/ screen
, tmux
, et al., but if all you want to do is see the output on some other device, then usually all you have to do is write to it.

- 58,310