I was wondering if there was any way to, via SSH, have the terminal "copied" to my HDMI output. Or at least be able to redirect the output of specific terminal-only programs to HDMI.

  • That is really interesting but I don't think you can "replicate" your SSH session to another output. You can possibly run a custom console, that saves everythign to a file and have another program read that file,and prin what you are doing and the HDMI screen(but text only). But allot of sources suggest VNC (because VNC is running on the screen and you just control the screen) to do this. I know the UART has a debugging console that dumps data. You can launch software from SSH with the target output of HDMI too, like omxplayer. – Piotr Kula Mar 31 '14 at 17:24
  • Yeah, I want to do something similar to what omxplayer does with videos, but just output the text-only output from a program's execution. I haven't (yet) found a simple way to do this. – LookingForIdeas Mar 31 '14 at 21:27
  • Yea. I don't think SSH can do that, by design. But there might be some software, like a console logger that can read everything, and then on the HDMI screen have a live streamer that reads the log. That is the only way I can think off. Basically its a security risk, and SSH is all about max security, by design! – Piotr Kula Mar 31 '14 at 21:31
  • Well we can do it with omxplayer by default, the only difference is that omxplayer outputs movies. I basically want the same thing as omxplayer, but instead of a video being played, it's the output from a CLI program. – LookingForIdeas Mar 31 '14 at 22:03

This is a very rough workaround, but it might actually work :D (I don't have an RPi to test with, at the moment...)

Basically, what it does (should do) is copy the output from an ssh-Terminal to a local file and follow that file (tail -f) on the HDMI-tty-Terminal.

1) Log onto your RPi either using ssh or a Keyboard and a Screen. 2) Install tmux: (maybe the other option stated here will work, too)

    sudo apt-get install tmux

3) open crontab (sudo crontab -e) and add this line:

    @reboot tmux new-session -s GREETINGS

(or use any other way to execute that line on startup, GREETINGS can be anything, as long as it's the same in step 6) )

4) reboot your RPi.

5) Connect using ssh and type

    bash | tee /home/pi/term.log

Which will copy output from your shell into the term.log file.

6) Tell the tmux Terminal on the Machine to write everything it sees in the file:

    tmux send-keys -t GREETINGS "tail -f /home/pi/term.log$'\n'

7) You should be good to go.

(when you exit ssh with the exit command, you will have to type it twice because you actually opened a bash shell within your ssh session. Also, you might want to delete the logfile at reglular interval (write a cronjob!), since it will hold the output of every command you ever typed.)

  • 2
    Haha wow, this sounds really hackish, for something that seems so simple! (I'm not saying your solution is poor, I'm just surprised there isn't a program that easily does something like omxplayer, but takes as its input a program, and outputs only text to HDMI.) – LookingForIdeas Mar 31 '14 at 22:50

You can do replications of terminals the via program screen (likely need to install it with a sudo apt-get install screen)

On the SSH, run the program screen with no args, it will display a big copywrite message and ask you to press space, it will look like all it did was clear your screen, but this is actually a new virtual screen running over the top of what you had before

Now on the HDMI, login and/or open a shell of the same user and run screen -x. Instead of opening a new virtual screen, it will attempt to connect to a virtual screen thats already running, leaving you with one virtual shell running between to different interfaces (SSH and HDMI).

If you kill the virtual shell then both windows will quit and go back to normal.

I learned about this use-case via Using screen for remote interactions though that blog entry is trying to do something more complex then what you implied via your question.

P.S. if either of the interfaces is via an xterm (or something with its own scrollback), don't try and use the scroll-bar, it doesn't work the way you expect. There is a way to scrollback in a screen, see the manpage for details.

  • 1
    After a bit more testing, the best results come from opening device with smallest character display area FIRST. The connecting 'screen -x' will box down the size of the first. If run the other way, the smaller view becomes a cropped view of the larger, and depending on the difference in size, useless. – Mike Lutz Apr 1 '14 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.