Gnu Screen ; Command Parameter, Multi display mode & Copy Mode

I wrote this Gnu Screen guide in December ’08 with the previous incarnation of linux.com in mind. January 2009 however, linux.com started on its new and exciting path as a community site and the article just sat on my machine, waiting. So I decided to publish it on my blog in a four part series over the following month. Maybe someone can use it 😉

Have you ever had to run a time consuming process (say mkfs or compiling something) over a shoddy ssh connection? Or cleanly run several commands in parallel without having several open connections to that server? Or maybe you were programming and wanted a mysql prompt, a bash prompt and several text editors open? How about that ssh tunnel you need open and dont want to close by accident? And did you ever need to perform the same task on several different machines? Or connect to a serial terminal? Or maybe you just want a log file of what you re doing..
These are day to day situations any linux user will run into, that can be quite frustrating. That is, before you discover Gnu screen!

“Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.” Or at least, thats what the site calls it. Sounds easy enough, but there are an amazing amount of different uses for this incredible piece of software. The above list is some of the uses I could readily think about – some of the ways I regularly use screen, but like any decent linux tool – the sky really is the limit! I’ll be looking into different issues, so lets jump into some of the practical solutions for those problems.

The fun stuff – Command Parameter
So far for the basics. We ve covered the strenght of being able to attach & detach a session, but screen has a wad of other options that prove fun toys.

Screen allows you to provide a command as a parameter.

screen <Screen Parameters> <command> <Command Parameters>

Screen executes the command given in the parameter. The parameters before the command are parsed by screen, the parameters after the command are passed on to the command. Without additional parameters, screen will open a session, execute the command and close afterwards. Screen cleans up after closing so any output to the terminal is erased afterwards.

$ screen ls

[screen is terminating]

While this might not seem too spectacular, this really opens a world of possibilities.
The first benefit is obviously when starting a remote command you don’t want interrupted by a failing connection. You could right as easily start a screen session and type the commands there, but in the end, you ‘ll notice that typing “screen” before the command is a tad quicker than doing it in the two passes. This is of course only the case if the command you need to run does not finish with any meaningfull output you need to study.. although if it does, you can always pipe it into a file. I frequently use this for moving files or even running a vi or emacs session

screen mv foo bar

The other and most important benefit is scripting. The option to run commands in a screen session out of a script allows for a broad spectrum of different possibilities. My favorite example is a screen – ssh wedding..

• How about that ssh tunnel you need open and dont want to close by accident?

One of my daily screen applications is an icon I have on my desktop. It opens an ssh tunnel to a designated server, authentication over ssh is handled by a public key and the screen options are as such that the session is either created or reattached. All my outgoing mail trafic is tunneled trough ssh to make sure that I dont have to change servers depending on what location I am working at.

#!/bin/bash

if [[ $( screen -ls | grep -c tunnel.Gen ) == 1 ]]

then

   gnome-terminal -e "screen -r tunnel.Gen" --hide-menubar -t "Gen"

else

  screen -d -m -S tunnel.Gen ssh user@host -L 25025:smtp.server.com:25

  gnome-terminal -e "screen -r tunnel.Gen" --hide-menubar -t "Gen"

fi

The workings of the script should be quite obvious, so I’ll skip that part and shed some light on the screen parameters. The “screen -r ..” part should be clear by now, this reattaches the screen session. The “-d -m” option tells screen to create a new session that is not attached to the terminal. And the “-S” option names the session, as we discussed before.
Thus effectively creating a tunnel window that can be automatically closed & opened at will, without losing the tunnel; and can effectively be terminated by exiting the ssh connection.

The Fun Stuff – Multi display mode
When we were talking about reattaching an attached session, we talked about another option instead of detaching the session.
Screen allows multi display mode. Before we get all excited, I want to point out a small detail in the setup. The users need to have access to the screen session. As we discussed before, this means they somehow both need the same user rights. This can be achieved by both logging in as the same user or by sudo or the likes. Two users on the same account does admittedly sound messy on a sysadmin level, but this might actually be worth while.

Multi Display Mode allows different users to connect to the same screen session together. This provides a powerfull tool for teaching someone terminal related knowledge in a shared environment or even have an attempt at solving an advanced problem together. To start such a session, both users should be able to access the same session (user). One of them starts the session as usual – preferably with an easy name.

screen -S Shared

And then have the other person connect to the session using the “-x” parameter.

screen -x Shared

& that will give you a nice shared session where you can have some fun together.

This is a trick that thoroughly helped me when simultaneously installing several servers with a colleague some years ago. This way we could continue each others work when necessary and avoided conflicting operations on the same machine.

This technique has been featured on Linux.com before though. Using screen for remote interaction by Philip J. Hollenback. The article goes in much more detail, although I have to admit the setuid aspect Really sets me off. The security consequences are just too big. But no comment on screen on that part. There is simply no way to do what needs to be done without the setuid flag. The other option would be to have the sessions available to all users and that would be an actual flaw, while the setuid flag is a potential flaw.

In the end, we can only conclude that this is a powerful option with lots of potential; but only under the right special circumstances.

The Fun Stuff – Copy Mode
After using screen for a while, one thing that will probably bother you is that the classic shift – pgup / pgdown doesnt work. Being unable to scroll back to earlier output or check command output beyond one page soon turns out to be quite the nuicance. To solve this, copy/scrollback mode – or vi command mode – can be used.

C-a esc     (copy)        Enter copy/scrollback mode.

This opens the buffer in a vi like mode where you can scroll back and forth in the buffer and use a whole set of different commands. Commands for scrolling around in the buffer, several ways of searching the text, several commands for selecting text in different patterns and yanking it for using elsewhere.
To make full use of the numerous keys in this mode, you should look up the “copy” chapter in the screen man page.

The articles in this series were updated to gertschepens.be; These articles focus on the following topics..

• The Simple stuff
  • Slightly more advanced stuff
• The fun stuff
  • Command Parameter, Multi display mode, Copy Mode
  • Nethack, Different screen windows, Sending commands to all screen windows
  • Different regions, Logging, Screen Window Types
  • the .screenrc