pages tagged screenyakkinghttp://yakking.branchable.com/tags/screen/yakkingikiwiki2014-08-20T11:00:12ZAdvanced uses of GNU screenhttp://yakking.branchable.com/posts/screen-advanced/Richard Maw2014-08-20T11:00:12Z2014-08-20T11:00:06Z
<p><a href="http://www.gnu.org/software/screen/">screen</a> is sometimes denounced for its bloat, usually by <a href="http://tmux.sourceforge.net/">tmux</a>
proponents, but these features come in useful, and screen's wide
availability makes it useful to learn these features.</p>
<h1>Copying and pasting text</h1>
<p><code>^A[</code> opens selection mode. This lets you scroll through your output and
select sections by pressing enter then moving your cursor to the end of
your selection and pressing enter again.</p>
<p>You can paste the selection by pressing <code>^A]</code>, which will input the
previously selected text, so you can save useful snippets of a command
by copying with <code>^A[</code>, opening a text editor, and pressing <code>^A]</code> to
paste it.</p>
<h1>Customising your caption line</h1>
<p>If you opened multiple screens in the same session, you will see a bar
at the bottom listing which screens are open. This is called the
caption bar.</p>
<p>If you want to always see it, you need to run the <code>caption always</code>
command.</p>
<p>You can either add it to your <code>~/.screenrc</code> file, for it to always
happen when you open a terminal, or invoke it directly on the screen
command line by pressing <code>^A:</code> to open the command line, then enter
<code>caption always</code> and press enter to run the command.</p>
<p>Like your shell's prompt, the caption bar can be customised. This is
done by entering <code>caption string $SPEC</code>.</p>
<p>There are many options possible, and referring to the <a href="http://linux.die.net/man/1/screen">screen(1)</a>
manpage is more useful than memorising them. The following example lists
the number and title of all screens in the caption, and highlights the
current screen in red:</p>
<pre><code>caption string "%?%F%{.R.}%?%3n %t%? [%h]%?"
</code></pre>
<h1>Screen config for complicated setups</h1>
<p>Instead of specifying a command to run when you start your screen session,
you can pass a path to a configuration file to run instead.</p>
<p>For example, you could put this in a config file for an <code>irssi</code> session:</p>
<pre><code>$ cat >irssi-screen-config <<EOF
screen -t irssi irssi
EOF
</code></pre>
<p>With this config you can then put the following command in an appropriate
place to start services, and have your computer start an irssi session
in a screen session on start-up.</p>
<pre><code>$ screen -D -m irssi-screen-config
</code></pre>
<p>You can also use the hash-bang line of a file to turn your config file
into a screen script.</p>
<pre><code>$ cat >irssi-screen-config <<EOF
#!/usr/bin/screen -Dm
screen -t irssi irssi
EOF
</code></pre>
<!-- TODO: will screen -Dm be sufficient in hashbang line? -->
<h1>Serial console client</h1>
<p>It is common for high-end switches and development boards to have a
serial port as a back-up control interface, so when everything else is
failing there's still a way to diagnose, and potentially fix a problem.</p>
<p>When appropriate cables have been connected, your machine will typically
have added a <code>/dev/ttyUSB0</code> device node to represent the connection.</p>
<p>Reading and writing to this device will send and recieve data along
the serial port line. However, in typical embedded linux appliances the
other side of the serial connection is a <a href="http://man8.org/linux/man-pages/man8/agetty.8.html">getty</a>, or login console.</p>
<p>To communicate with this, you need a client application.</p>
<p>Given this article is about screen, it should come as no surprise for
me to announce that screen can act as such a client.</p>
<p>Rather than doing <code>screen $COMMAND</code>, to run a command in a local tty,
you run <code>screen /dev/ttyUSB0 115200</code>.</p>
<p>See the "Window Types" section of <a href="http://linux.die.net/man/1/screen">screen(1)</a> for details about what
the 115200 option is, and when you would need to change it.</p>
<p>This is arguably a sign of bloat, that a program about terminal
multiplexing includes a serial console client, however it's convenient,
as screen is widely available on Linux distros.</p>
<h1>Filter commands</h1>
<p>Use <code>^A:</code> to open the screen command line. Enter <code>exec COMMAND</code> to run
that command.</p>
<p>A sequence of <code>!</code>, <code>.</code> or <code>:</code> symbols before the command can be used to
specify whether the input comes from your keyboard (the screen's input)
or the output of the command running in your screen.</p>
<p>Exactly which symbols to use is a bit of a mystery, but <code>!!</code> replaces
your shell with another program talking to the terminal. For anything
else, see the <a href="http://linux.die.net/man/1/screen">screen(1)</a> manpage.</p>
<h2>Sending files with xmodem</h2>
<p><a href="http://en.wikipedia.org/wiki/XMODEM">xmodem</a> is a protocol for file transfer over a serial connection.</p>
<p>It's old and fragile, but it's simple, so development boards sometimes
have it as a fall-back for when everything else fails.</p>
<p><a href="http://linux.die.net/man/1/sz">sx(1)</a> is a tool to communicate over <a href="http://en.wikipedia.org/wiki/XMODEM">xmodem</a>. It can also do the
<a href="http://en.wikipedia.org/wiki/YMODEM">ymodem</a> protocol by invoking it as <code>sx --ymodem</code>.</p>
<p>After opening the command line with <code>^A:</code>, enter <code>exec !! sx $FILE</code>
to send that file over xmodem.</p>
<p><a href="http://en.wikipedia.org/wiki/XMODEM">xmodem</a> isn't completely reliable, so it may be necessary to re-run
the command.</p>
GNU screen the terminal multiplexerhttp://yakking.branchable.com/posts/screen/Richard Maw2014-08-06T11:00:20Z2014-08-06T11:00:13Z
<p>GNU <a href="http://www.gnu.org/software/screen/">screen</a> is a useful tool, it has been mentioned in multiple
earlier articles as a good way to keep a program running after you log
out of a server.</p>
<p>Screen runs commands in sessions. Each session can have multiple screens
in which commands are run, which can be a more useful interface to
multiprocessing than running jobs in the background.</p>
<p>A screen session can be connected to by multiple terminals, and can be
detached from entirely, so there's no user reading the command's output.</p>
<h1>Creating a session</h1>
<p>The simplest use of screen is to simply enter <code>screen</code> at which point
it creates a new session, running your shell.</p>
<p>Commands other than the default of your shell can be executed too. You
can run <code>screen tail -f /var/log/foo.log</code> to watch the logged output of
a command.</p>
<p>You can specify the name of the session with the <code>-S</code> argument, which
can be used later to re-join or kill a session by name.</p>
<h1>Entering commands</h1>
<p>Screen has many default key-bindings for running commands. These are
mostly prefixed by the escape key. This defaults to <code>^A</code> (read as holding
Ctrl an pressing the a key).</p>
<p><code>^A</code> is commonly used by <a href="http://www.gnu.org/s/emacs/">emacs</a> users to move the cursor to the
beginning of the line. It is possible to re-bind to a different key by
putting <code>escape $KEY</code> in your <code>~/.screenrc</code>.</p>
<p><code>escape ^Bb</code> will make screen use <code>^B</code> for its escape character, rather
than <code>^A</code>.</p>
<p>Commands that had not been bound can be entered by entering the <code>^A:</code>
command (hold Ctrl, press a, then press :). This will open a command
line interpreter, where you can enter other commands.</p>
<h1>Opening a new screen in your session</h1>
<p>The <code>screen</code> command will open a new screen in the same session. The
keyboard shortcut for this is to enter <code>^Ac</code>, which opens a new screen
and runs a shell in it.</p>
<p>To run a specific command in your new screen, just like how we create
the initial screen session, just in the screen command line, rather than
your shell's command line.</p>
<p>For example, entering <code>screen tail -f /var/log/foo.log</code> in the command
line opened by pressing <code>^A:</code>, will open a new screen and read the output
of <code>foo.log</code> into it, which can be used to monitor the logs of a command
being run in another screen.</p>
<h1>Switching screens</h1>
<p><code>^Aa</code> will switch between your current screen and your previous screen.</p>
<p>Your open screens are listed in the caption at the bottom of the
screen. Pressing <code>^A$NUMBER</code> will switch to that screen, so <code>^A1</code> will
switch to the first screen.</p>
<p><code>^A"</code> will open a menu of screens to switch to, including what command
is running in that screen, which is useful if the information in the
caption bar isn't sufficient.</p>
<p>The command to switch screens is called <code>select</code>, so running <code>select 1</code>
in screen's command line will switch to screen 1.</p>
<h1>Splitting screens</h1>
<p>Using screen to manage multiple commands is already an improvement over
bash's job control.</p>
<ol>
<li>The caption bar shows you which commands are running</li>
<li>You don't need to background a command to have multiple running</li>
<li>The output from multiple commands doesn't get interleaved into an
incomprehensible mess, since the output is separated by screen.</li>
</ol>
<p>However, we currently can only see the output of one command at a time,
so we can't use our earlier example of looking at the logged output of
the foo command, while running other commands.</p>
<p>To handle this, <a href="http://www.gnu.org/software/screen/">screen</a> allows you to split your view into multiple
windows.. <code>^As</code> produces a horizontal split, so you can have one window
at the top, and a different below it.</p>
<p><code>^A|</code> creates a vertical split, so you can have a different window on
the left and the right.</p>
<p>Various windows can be cycled between with the <code>^A<TAB></code> key.</p>
<p><code>^AX</code> will remove the current split, and <code>^AQ</code> will remove all windows
except the one which currently has focus.</p>
<h1>Closing screens in your session</h1>
<p>When the primary process of a screen terminates, the associated screen
will close, so if you enter <code>exit</code> on your shell, the screen will close.</p>
<p>If a screen is stubbornly refusing to exit, you can run <code>^Ak</code> to kill
the current screen.</p>
<h1>Closing a session</h1>
<p>When all commands run in a screen session exit, the session is closed.</p>
<p>If a command is not easily closed or you do not care for cleanly closing
it, then you can press the <code>^A\</code> shortcut to kill everything, or entering
the <code>quit</code> on the screen command line.</p>
<h1>Detaching from a session</h1>
<p>A screen session can be left running without any user being connected
to it. This can be accomplished by creating one as before, and pressing
<code>^AD</code> to detach yourself from it.</p>
<p>A screen can be started in detached mode by starting it as <code>screen -d -m</code>.</p>
<h1>Joining an existing session</h1>
<p><code>screen -x</code> will join an existing session, even if there is currently
a user already attached. This allow multiple users on the same screen
session, but can behave strangely if each user has a different terminal
size.</p>
<p>The latest session with no users can be re-attached to with <code>screen
-R</code>. This can fail if the latest screen session has a user, so there's
the <code>-d</code> option too, which will detach the session first if necessary.</p>
<p>The <code>-D</code> command is useful, since you can also provide the command
you want to run as the first argument, so <code>screen -D -R tail -f
/var/log/foo.log</code> will detach and re-attach to an existing session if
it exists, otherwise it will create a new one reading log output.</p>