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– Celada2015-06-14 09:04:59 +00:00Commented Jun 14, 2015 at 9: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– Euphorbium2015-06-14 09:14:29 +00:00Commented Jun 14, 2015 at 9:14
- 1What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?Gilles 'SO- stop being evil'– Gilles 'SO- stop being evil'2015-06-14 13:25:43 +00:00Commented Jun 14, 2015 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
screenis installed - Log in with SSH
Create a new screen session
screenAttach 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-rresume session and-xmulti-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.
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.
- 1Thanks for going beyond what I thought of doing to make it more clean and automated :)Celada– Celada2015-06-14 11:39:45 +00:00Commented Jun 14, 2015 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– Euphorbium2015-06-14 13:35:56 +00:00Commented Jun 14, 2015 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.