|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
GNU Screen is a simple but at the same time programmable windows manager. It is often called terminal multiplexer but the key functionality of screen is in the area of windows management: creation, destruction and resizing of windows. For example it can split the console screen horizontally and display two windows at the same time. Screen is a Unix program. For good Windows terminal emulator see Teraterm
In addition to the ability to run many shell processes in a single terminal, screen provides classic windows management capabilities -- the ability to split terminal into regions (horizontal stripes of varying length, each containing its own session. What is also important is that like VNC screen provides the ability to detach the terminal emulator from the running programs and then reattach the same or new terminal to them.
This feature is enabled by default.
|
An important feature of screen is that like VNC it provides the ability to detach the terminal emulator from the running programs and then reattach the same or new terminal to them. |
This means screen will keep shells and programs running in all windows that you opened even if you accidentally disconnected from the remote server or closed the terminal emulator. Like VNC screen also permits to share a terminal (in read-only mode) with someone else in real time. This permits to collaborate on a project by several remote users located in different places.
Screen has a certain architectural affinity to the orthodox file managers (OFM ), especially deco as well as orthodox editors like vi and THE (the power of command line).
Like in vi in screen you have to hit certain prefix to get to command line. The default prefix is Ctrl-A. For example Ctrl-A,C will open window.
This availability of command line operations and related scriptability via screenrc file makes screen attractive to system administrators who prefer blend of power and simplicity. Like in all orthodox utilities there is an extensive set of commands that can used to modify the behavior of screen.
Ctrl-a is called attention/command key and is similar to Esc in vi (you also can change Ctrl-A to another sequence, if you wish).
If the colon (":") is entered after it screen switched to command mode and you'll see a highlighted colon prompt at the bottom of the screen. And like in vi you can enter commands that change the behavior of the screen and modify its current configuration. For example you can open and close windows, change size of windows, etc. For example you open new window also by typing command (which is equivalent to the shortcut Ctrl-A,C that we discussed above):
Ctrl-A: screen
So shortcut Ctrl-A,C and command Ctrl-A: screen are synonnyms. This is just an assicoation that is defined in .screenrc file. You can start screen using arbitrary screenrc file using option -c, for example
screen -c ~myhome/.screenrc_`uname`
This example demostrated that you can have several .screenrc files and use the one that suits current environment. You can also execute predefined sequences of screen commands stored in the files (screen scripts) using the command source. One common application is the execution of the set of command creating a paricular combination of windows and loading parcitular applications into each window. Foe example you can load Perl in debugging mode on one window, vi in another and Perl POD browser in the third creating poor man IDE environment. For example
source .screenrc_perl
or
source ~myhome/perl.screenrc
That provides you with the flexibility to have several predefined sets of windows working on a particular task, the capability that improves your productivity dramatically as you can polish the arrangement and gradually connect a set of useful shortcuts as you gain experience with the environment (in the example above working with Perl). System administrators can (and should) have a custom part of configuration encoded for particular hosts (that's the way I used to work) :
source ${HOME}/${HOST}.screenrc
|
Due to availability of command line interface and scriptability Screen can be considered to be a member of "orthodox" family of utilities which include orthodox file managers (mc, FAR, etc) and orthodox editors (vim, Xedit, THE, etc). Command line can be activated with Ctrl-A: after that you can enter any command from the screen command set to modify behavior of the screen or execute sets of commands (screen script) from particular file using command source. |
A typical application of this capability is to launch a predefined set of windows at screen startup., for example:
source $HOME/.screenrc # read in your normal screenrc
screen top # now start opening windows
screen -t irc epic # with the -t option it's possible to set the window title
screen -t mail 8 mutt # you can also specify the window number to launch in
screen -t messages 9 tail -f /var/log/messages
In X-windows world screen inspired several minimalist windows managers which usually are bungled with linux mini-distributions. Classic example of this genre is ratpoison (the name suggest that it is one of the few that not support mouse "out of principle" ;-).
Screen is portable and is an almost a standard utility on all flavors of Unix. It is often preinstalled by default in Linux distributions (for example, Suse 10). And it is easily installed in Solaris, AIX and HP-UX. For example Solaris 10 package can be found on sunfreeware.com:
screen-4.0.2-sol10-intel-local.gz Screen provides an ANSI/vt100 terminal emulator, which can multiplex up to 10 pseudo-terminals - installs in /usr/local. There are further configuration steps in the /usr/local/doc/screen/INSTALL. The etc and terminfo directories containing other relevant files are in /usr/local/doc/screen. The screen package may also require that you install the ncurses package.
Using it, you can run any number of console-based applications -- interactive command shells, curses-based applications, text editors, etc. -- within a single terminal. Many administrators who use screen open a dozen or even more sessions.
Screen can be used in two ways (you can use both local and remote screen instances simultaneously by changing control character in local to say Ctrl-\ via .screenrc, see below):
A nested master-slave invocation of screen is also possible, but it is unclear how practical it is. See Jason White page and my screenrc and my slave screenrc by Tim Chambers. Here is how he explained this method in Slashdot post:
You run an "outer" screen session (the "slave" session) that in turn runs an "inner" (or "master") session. You use the regular escape sequence (Ctrl-A d) to detach from the master, and you map Ctrl-^ to be the control key for the slave session. If you press Ctrl-^ while using screen this way, you'll see one process in the slave session. It's running ssh-agent. That's the key to using ssh with screen. The slave's only purpose is to run ssh-agent. The master runs as a child of that. Consequently, all shells in the master session are running under the ssh-agent. Just run ssh-add from any master shell, and then all shells have your ssh identity.
As we mentioned above, after starting screen you need to open windows using the command Ctrl-a c. Every window in screen is identified by a unique number. The first window is usually numbered 0 (you can change this to one if you do not like counting from zero). For each created windows screen starts default shell. After that user for example can open remote session to a particular server and rename it to simplify recognition after switching to another (an optimal typical number of windows for one screen instance is around a dozen). You can use multiple screen instances each with its own set of servers to connect (DMZ servers, database servers, etc).
Minimum set of commands necessary to use screen productively includes just five commands:
- Ctrl-a c to create a new console (Ctrl-a N -- lists the number of the active windows)
- Ctrl-a <number> to switch between them (Ctrl-a n, Ctrl-a p or Ctrl-a Ctrl-a will work too providing previous and next windows, but are less convenient and there are two of them instead of one)
- Ctrl-a " (windows) Show a list of active windows. You can navigate this list with the arrow keys (or vi-style, with j and k), and pick a window to activate by pressing Enter when it's highlighted. As this is one of the most often used commands you will be better off redefining this command as Ctrl-a space (see .screenrc examples on how to do that).
- screen -r. To reattach to screen you left by closing terminal session. You can also detach just by closing the terminal emulator that contains the session. Neither of these actually end your session. All they do is unbind your session from the current terminal. All of the programs you started running within screen are still running. This command can be incorporated to your profile.
- Ctrl-a Ctrl-\ (quit) Kill all windows and terminate screen.
There are also several more advanced features that can improve your productivity. Among them I would like first of all mention regions.
Regions can dramatically improves your productivity in pure command line
environment. This feature turns screen in rudimentary windows manager able
to create "strips" non-overlapping horizontal zones each of which corresponds
to a separate shell window. To split the screen into two regions just press
C-a S. The current window will split into two separate areas
with the bottom area blank. To switch to the bottom part press
C-a [Tab]. If you need to create a new shell in the new window,
so press C-a c. If you want to see one of the existing sessions
press Ctrl-a " and select
the necessary session. You
can create more regions by pressing C-a S again: each time
the current "strip" will be split into two. Tabs display the active region
shell name in its title bar. You can also switch between tabs being in a
region, so e.g.: you have 4 tabs and 2 regions. Each region can display
one of these tabs. A nice trick is that upper region can react on the change
of the particular environment variable and display either file you are editing
or the listing of the current directory. This arrangement is close for the
OFM paradigm. You can change the size of each region by entering resize
[size], where size is the number of lines.
| The key additional feature of Screen that you need to master after mastring basic commands is split command. |
Here is slightly more elaborate set of commands, which we will call Level 1 command set. It includes regions-related commands:
- Ctrl-a ' (select)
- Prompt for a window name or number to switch to.
- Ctrl-a " (windowlist -b)
- Present a list of all windows for selection.
- Ctrl-a 0 (select 0)
- ... ...
- Ctrl-a 9 (select 9)
- Ctrl-a - (select -)
- Switch to window number 0 - 9, or to the blank window.
- Ctrl-a tab (focus)
- Switch the input focus to the next region.
- Ctrl-a Ctrl-a (other)
- Toggle to the window displayed previously.
Note that this binding defaults to the command character typed twice, unless overridden. For instance, if you use the option "-e]x", this command becomes "]]".- Ctrl-a a (meta)
- Send the command character (Ctrl-a) to window. See escape command.
- Ctrl-a A (title)
- Allow the user to enter a name for the current window (useful fo naming each window according to the purpose (for example each can represent a different directory).
- Ctrl-a b
- Ctrl-a Ctrl-b (break)
- Send a break to window.
- Ctrl-a B (pow_break)
- Reopen the terminal line and send a break.
- Ctrl-a c
- Ctrl-a Ctrl-c (screen)
- Create a new window with a shell and switch to that window.
- Ctrl-a C (clear)
- Clear the screen.
- Ctrl-a d
- Ctrl-a Ctrl-d (detach)
- Detach screen from this terminal.
- Ctrl-a D D (pow_detach)
- Detach and logout.
- Ctrl-a f
- Ctrl-a Ctrl-f (flow)
- Toggle flow on, off or auto.
- Ctrl-a F (fit)
- Resize the window to the current region size.
- Ctrl-a Ctrl-g (vbell)
- Toggles screen's visual bell mode.
- Ctrl-a h (hardcopy)
- Write a hardcopy of the current window to the file "hardcopy.n".
- Ctrl-a H (log)
- Begins/ends logging of the current window to the file "screenlog.n".
- Ctrl-a i
- Ctrl-a Ctrl-i (info)
- Show info about this window.
- Ctrl-a k
- Ctrl-a Ctrl-k (kill)
- Destroy current window.
- Ctrl-a l
- Ctrl-a Ctrl-l (redisplay)
- Fully refresh current window.
- Ctrl-a L (login)
- Toggle this windows login slot. Available only if screen is configured to update the utmp database.
- Ctrl-a m
- Ctrl-a Ctrl-m (lastmsg)
- Repeat the last message displayed in the message line.
- Ctrl-a M (monitor)
- Toggles monitoring of the current window.
- Ctrl-a space
- Ctrl-a n
- Ctrl-a Ctrl-n (next)
- Switch to the next window.
- Ctrl-a N (number)
- Show the number (and title) of the current window.
- Ctrl-a backspace
- Ctrl-a h
- Ctrl-a p
- Ctrl-a Ctrl-p (prev)
- Switch to the previous window (opposite of Ctrl-a n).
- Ctrl-a q
- Ctrl-a Ctrl-q (xon)
- Send a control-q to the current window.
- Ctrl-a Q (only)
- Delete all regions but the current one.
- Ctrl-a r
- Ctrl-a Ctrl-r (wrap)
- Toggle the current window's line-wrap setting (turn the current window's automatic margins on and off).
- Ctrl-a s
- Ctrl-a Ctrl-s (xoff)
- Send a control-s to the current window.
- Ctrl-a S (split)
- Split the current region into two new ones.
- Ctrl-a t
- Ctrl-a Ctrl-t (time)
- Show system information.
- Ctrl-a v (version)
- Display the version and compilation date.
- Ctrl-a Ctrl-v (digraph)
- Enter digraph.
- Ctrl-a w
- Ctrl-a Ctrl-w (windows)
- Show a list of window.
- Ctrl-a W (width)
- Toggle 80/132 columns.
- Ctrl-a x
- Ctrl-a Ctrl-x (lockscreen)
- Lock this terminal.
- Ctrl-a X (remove)
- Kill the current region.
- Ctrl-a z
- Ctrl-a Ctrl-z (suspend)
- Suspend screen. Your system must support BSD-style job-control.
- Ctrl-a Z (reset)
- Reset the virtual terminal to its "power-on" values.
- Ctrl-a . (dumptermcap)
- Write out a ".termcap" file.
- Ctrl-a ? (help)
- Show key bindings.
- Ctrl-a Ctrl-\ (quit)
- Kill all windows and terminate
screen.- Ctrl-a : (colon)
- Enter command line mode.
- Ctrl-a [
- Ctrl-a Ctrl-[
- Ctrl-a esc (copy)
- Enter copy/scrollback mode.
- Ctrl-a ] (paste .)
- Write the contents of the paste buffer to the stdin queue of the current window.
- Ctrl-a {
- Ctrl-a } (history)
- Copy and paste a previous (command) line.
- Ctrl-a > (writebuf)
- Write paste buffer to a file.
- Ctrl-a < (readbuf)
- Reads the screen-exchange file into the paste buffer.
- Ctrl-a = (removebuf)
- Removes the file used by Ctrl-a < and Ctrl-a >.
- Ctrl-a , (license)
- Shows where screen comes from, where it went to and why you can use it.
- Ctrl-a _ (silence)
- Start/stop monitoring the current window for inactivity.
- Ctrl-a * (displays)
- Show a listing of all currently attached displays.
Here are some examples of keyboard bindings:
bindkey -d # Show all of the default key bindings. The application mode entries are marked with [A].bindkey -k k1 select 1 # Makes the "F1" key switch to window one.bindkey -k F1 command # Makes the F11 (not F1!) key an alternative screen escape (besides `Ctrl-a').
You can also easily change Ctrl-A (the default attention/command key sequence) to another sequence. This can be done either via putting command escape into .screenrc or via a switch when you start screen.
If you invoked screen by using "screen
-e ^Ww" you can see that ^W
became attention/command key combination. So
^W-? gets the Help screen.
Ctrl-A and then ? no longer worked.
escape xy
Set the command character to x and the character generating a literal command character (by triggering the "meta" command) to y (similar to the -e option). Each argument is either a single character, a two-character sequence of the form "^x" (meaning "Ctrl-x"), a backslash followed by an octal number (specifying the ASCII code of the character), or a backslash followed by a second character, such as "\^" or "\\". The default is "^Aa".
For example if you add
escape ^\\
into the .screenrc you will see that ^\ became attention key sequence instead of default ^A.
It is also important to make screen more user friendly. In order better see what open windows you have you can do it by adding the following lines to .screenrc :
1 hardstatus alwayslastline
2 hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=
kw}%?%-Lw%?%{r}(%{W}%n*%f %t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}
%Y-%m-%d %{W}%c %{g}]'
In his paper Screen Tips & Tricks Łukasz Olender suggests several other variants:
But so as not to get lost in these windows, I suggest you create tabs similar to those found in web browsers. You can do this by writing to your configuration file
~/.screenrcone of the following codes:hardstatus alwayslastline hardstatus string '%{= mK}%-Lw%{= KW}%50>%n%f* %t%{= mK} %+Lw%< %{= kG}%-=%D %d %M %Y %c:%s%{-}'or
hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r} (%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'or
hardstatus alwayslastline hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR} (%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}] %{=b C}[ %m/%d %c ]%{W}'With the first code each tab will have a number, a name plus time and date. The second one will give you tabs that will be created in the center and the active tab will be highlighted in red and also have the hostname displayed. The last code will additionally display the processor usage. You can create your own codes but it is a rather specialized task - I refer you to the system manuals for more information.
You can combine ideas from those into you own status line that suits your need. But in any case it is important to improve visibility of windows by using this capability of screen.
Dr. Nikolai Bezroukov
|
|||||||
Customizing the configuration file
Screen keeps its configuration file in the same vein that many applications do: in a dot file in your user’s home directory. This file is aptly named .screenrc. In my experience, most people use ~/.screenrc to do two things:
- Make a hardstatus line. This is basically a line at the bottom of the screen that lists your current terminal and all opened ones. It can also display the system clock and the hostname.
- Default screens on startup. It’s quite nice to have your IRC connection, mail client, and default SSH connections auto-start for you!
The lines below are numbered for reference. Your config file should not have numbered lines.
1 hardstatus alwayslastline 2 hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]' 3 4 # Default screens 5 screen -t shell1 0 6 screen -t shell2 1 7 screen -t server 2 ssh me@myserverOn lines 1 and 2, you are setting the hardstatus. Line 1 makes the hardstatus always show up as the last line. Line 2 is about what will be shown in the hardstatus line. In this case you will see something like so at the bottom:
Using Screen
From your ssh login prompt enter the following command
screen
or
screen -S 1
and select your profile option.
-S sessionname – When creating a new session, this option can be used to specify a meaningful name for the session. This name identifies the session for “screen -list” and “screen -r” actions.
... ... ...
Customise Screen-profiles
If you look in the bottom right corner you’ll see there’s an “F9 Menu” you can press F9 to reconfigure your screen profiles. Once it opens you should see similar to the following screen here you can see list of changes you can do
Sample screenshots for screen-profile options
screen-4.0.3-1.aix5.1.ppc.rpm 30-May-2008 20:58 548K
screen: detach to avoid repeat loginsEntering:
screen -d(detach screen), or hitting Ctrl-A then D whilst in a screen session, will detach your running screen, leaving it going in the background. This can be useful for running background jobs; it can also be useful for saving you frp, repeatedly logging into and out of machines. Start a screen session, log in to another machine, and detach the screen. Reattach the screen:
screen -rand you'll be back connected to the ssh session, without having to type your password again.
screen: connect multiple users
When you're bugfixing, sometimes you really need to be able to see what the user who brought the problem to you is doing, and what output they're getting. You can use screen to avoid having to actually walk all the way over to their desk. Log on to the user's machine as them, then type:
screen -S debugThen get them to type:
screen -x debugand they'll join your screen session. Then whatever they do will be replicated on your screen (and vice versa). ('debug' is just the identifier; you can use any name you want.)
# ===================================================================== # File: $HOME/.screenrc of Sven Guckes # Available: http://www.guckes.net/Setup/screenrc # Purpose: Setup file for program "(GNU) screen" # written by: Sven Guckes setup-screenrc(at)guckes.net # Latest change: Mon Mar 31 04:35:49 CEST 2008 # Length and size: ca 1460 lines and ca 56.300bytes # ===================================================================== # Latest user version: screen-4.0.3 [2006-10-23 15:10] 840602bytes # ==========================================================================
This is a project to produce an efficient way of filling a large area of screen space with terminals. This is done by splitting the window into a resizeable grid of terminals. As such, you can produce a very flexible arrangements of terminals for different tasks.
Read me
Terminator 0.8.1
by Chris Jones <cmsj@tenshu.net>
This is a little python script to give me lots of terminals in a single window, saving me valuable laptop screen space otherwise wasted on window decorations and not quite being able to fill the screen with terminals.
Right now it will open a single window with one terminal and it will (to some degree) mirror the settings of your default gnome-terminal profile in gconf. Eventually this will be extended and improved to offer profile selection per-terminal, configuration thereof and the ability to alter the number of terminals and save meta-profiles.
You can create more terminals by right clicking on one and choosing to split it vertically or horizontally. You can get rid of a terminal by right clicking on it and choosing Close. ctrl-shift-o and ctrl-shift-e will also effect the splitting.
ctrl-shift-n and ctrl-shift-p will shift focus to the next/previous terminal respectively, and ctrl-shift-w will close the current terminal and ctrl-shift-q the current window
Ask questions at: https://answers.launchpad.net/terminator/
Please report all bugs to https://bugs.launchpad.net/terminator/+filebug
It's quite shamelessly based on code in the vte-demo.py from the vte widget package, and on the gedit terminal plugin (which was fantastically useful).
vte-demo.py is not my code and is copyright its original author. While it does not contain any specific licensing information in it, the VTE package appears to be licenced under LGPL v2.
the gedit terminal plugin is part of the gedit-plugins package, which is licenced under GPL v2 or later.
I am thus licensing Terminator as GPL v2 only.
Cristian Grada provided the icon under the same licence.
Re: Using GNU screen's multiuser feature for remote supportPosted by Anonymous (66.189.xx.xx) on Wed 9 Jan 2008 at 16:15
The ^Amultiuser on is unnecessary, AFAIK. All that is necessary when two people are logged in as the same user is for one to start the screen session, then the other to connect to it with screen -x. #5
Re: Using GNU screen's multiuser feature for remote support
Posted by taylor (206.107.xx.xx) on Wed 9 Jan 2008 at 20:04That is true. I've used screen -x to attach to screen sessions in multiple locations simultaneously for a number of years, and you don't need to do anything else for it to work. #6[ Send Message ]
Re: Using GNU screen's multiuser feature for remote support
Posted by Anonymous (128.32.xx.xx) on Tue 22 Jan 2008 at 05:19
On the other hand, multiuser mode CAN be used to let two DIFFERENT users to access the same screen (so you don't have to share a login password or allow an SSH key with essentially full access to the account).
By default, this is not allowed on Debian, even if you turn multiuser mode on, but if you absolutely need this functionality, you can do it this way (I just tested it---I, of course, don't use it this way):
From: Jonathan Daugherty Subject: Re: binding ctrl-arrow Date: Wed, 4 Apr 2007 13:07:47 -0700 User-agent: Mutt/1.5.11
# a similar message was posted some time ago but I did not see any # answer. How can I bind the sequence ctrl+arrows (up, down, left # right)? In particular, I would like to enter copy mode with # ctrl-UpArrow. I tried something like # # bindkey -k ^ku copy I saw this trick somewhere: I do this by firing up cat to figure out what my terminal sees when I press Ctrl+Up and Ctrl+Down: address@hidden:~$ cat >/dev/null ^[[1;5A ^[[1;5B (Above produced by pressing Ctrl+Up, RET, Ctrl+Down.) Then, I add those strings to my .screenrc: bindkey ^[[1;5A prev bindkey ^[[1;5B next In my case, I use Ctrl+Up and Ctrl+Down to move around through my screens. This will only work as long as you're using a terminal that considers those equivalent to Ctrl+Up and Ctrl+Down respectively. I don't know of a way to get them to work universally, so I just stick to xterm (which is fine by me). HTH, -- Jonathan Daugherty http://www.b-tree.org
Re: binding ctrl-arrow
From: Giulio Bottazzi Subject: Re: binding ctrl-arrow Date: Thu, 5 Apr 2007 10:29:32 +0200
Hi Jonathan, to use cat to probe for keys is a fantastic trick! Thank you very much! I really enjoy this mailing list.! Actually, using xterm and your trick I'm able to do exactly what I want with
bindkey ^[[1;5A copy
Just to let you know: the same trick does also work in aterm using
bindkey ^[Oa copy
Best, Giulio.
From: Stephane Chazelas Subject: Re: Screen and Linux box characters Date: Tue, 24 Apr 2007 12:46:21 +0100 User-agent: Mutt/1.5.6i
On Tue, Apr 24, 2007 at 11:45:49AM +0100, Richard Cryer wrote:
> Hi.
>
>
>
> I use screen 4.0.2 on various Linux versions ranging from Redhat 7 up to
> Redhat Enterprise 4.
>
>
>
> However, it seem that Redhat 8 and onwards has a problem in that it
> won't let me display box characters, something that the application we
> run relys on to display the screen layouts correctly.
[...]
I'd suspect your terminfo entry for "linux" (or whatever $TERM
is before you start screen) is incorrect.
$ infocmp -L1 | grep -e charset -e acs -e Recon
should give you something like:
# Reconstructed via infocmp from file: /lib/terminfo/l/linux
acs_chars=+\020\054\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
enter_alt_charset_mode=\E[11m,
enter_pc_charset_mode=\E[11m,
exit_alt_charset_mode=\E[10m,
exit_pc_charset_mode=\E[10m,
Those tell scany application using the terminfo database
to find out about terminal capabilities how to display the
graphic characters.
You may also want to check that screen has been built to use the
terminfo database.
A strace -fe open -o /tmp/strace.out screen
Should tell you whether screen opens /lib/terminfo/l/linux or
some termcap file instead.
If it uses termcap, I would recompile screen so that it links
against ncurses or at least a ncurses version of libtermcap, as
those seem to be the the ones giving the best results.
Cheers,
Stéphane
From: Pieter Luteijn Subject: Re: sorting screens Date: Tue, 24 Apr 2007 20:03:41 +0200 (CEST) User-agent: SquirrelMail/1.4.8
> >> Hi. When I have multiple named screen windows, is there a way to sort >> them >> alphabetically? > > This is a longtime wish of mine as well .. > > -- > jean . .. .... //\\\oo///\\ > This is probably why people have been looking for a nice way to dump the windowlist to STDOUT (search archives..) Then you can do something useful with it, like filtering it through sort -k 2 | sed -e "s/^[ 0-9]\+ //" -e "s/ \+[^ ]\+$//" | sed -e "s/^/screen -p \"/" -e "s/$/\" -X number /" and then feeding that to win=0 while read almost_finished_command do eval $almost_finished_command $win win=`expr $win + 1` done (sort on the window titles, replace the irrelevant information around the titles (current window number, flags; this could be different for a different windowlist string...) with re-numbering commands, then add the actual numbers in a second pass and execute the commands) You can still use this (or something slightly better looking) to sort the windows if you have some way to capture the output of windowlist (e.g. cut and paste it with the mouse if your terminal emulator can do this) Pieter
From: Matt Dunford Subject: screen patch Date: Tue, 27 Feb 2007 00:02:28 -0500 User-agent: Mutt/1.5.13 (2006-08-11) Hi All, I just came across this list yesterday and am glad to see that screen is still alive and kicking. It's one of those programs I can't imagine living without. Anyway, here's a patch I updated recently for version 4.0.2: it adds two features I use alot. The first I call "toggle" (^aT). Oftentimes I do many screen commands in a row like creating five or six new windows. I do ^aT, then c c c c c (to create five more windows). When I want to cycle through them, I hit the space bar. Or if I want to go back n forth between windows, then n and p. All this to avoid hitting ^a every time I want to do a command. When I'm done and want to return to normal mode, I hit T to turn it off. The second jumps to the last window in the list (^a$) - like vi's 0 to go to the front of the line, $ to go to the end. It also adds an extra check for the -h option - makes sure you can't pass a non-digit as an argument. If anyone's interested in the patch, I'll clean it up. -- Sincerely, Matt Dunfordscreen-4.0.2.diff
Description: Text Data
From: Mag Gam Subject: New screen features -- groups Date: Mon, 19 Feb 2007 23:03:26 -0500 I have downloaded the latest-greatest-screen, and it has a new feature called 'group creation' which is a superset of 'windows'. I have a scenario like this:
2 production servers (prod1, prod2)
2 development servers (dev1,dev2)
4 Q/A servers (qa1,qa2,qa3,qa4)
How can I create 3 groups (prod, dev,qa), and have these servers included in them respectivly?
From: Igor Moroz Subject: Re: how to send commands to running screen sessions Date: Fri, 16 Feb 2007 12:23:41 +0300
В Чтв, 15/02/2007 в 19:00 -0300, Henrique Niwa пишет:
> Sometime ago i saw an email from the list explaining
> how to send commands to matching windows.
> like, for windows named sh send command xyz
> i accomplished some results using the stuff command,
> but i could not replicate the enter key, nor send it
> to multiple windows matching some pattern.
> Does anybody knows the correct syntax of the command?
Is it what you want?
http://www.math.utah.edu/docs/info/screen_19.html#SEC110
At
Command: at [identifier][#|*|%] command [args]
Execute a command at other displays or windows as if it had been entered
there. At changes the context (the `current window' or `current display'
setting) of the command. If the first parameter describes a non-unique
context, the command will be executed multiple times. If the first
parameter is of the form `identifier*' then identifier is matched
against user names. The command is executed once for each display of the
selected user(s). If the first parameter is of the form `identifier%'
identifier is matched against displays. Displays are named after the
ttys they attach. The prefix `/dev/' or `/dev/tty' may be omitted from
the identifier. If identifier has a # or nothing appended it is matched
against window numbers and titles. Omitting an identifier in front of
the #, * or % character selects all users, displays or windows because a
prefix-match is performed. Note that on the affected display(s) a short
message will describe what happened. Caution: Permission is checked for
the owners or the affected display(s), not for the initiator of the `at'
command.
--
Cul8r,
Igor ,)
From: Andy Harrison Subject: Re: how to send commands to running screen sessions Date: Fri, 16 Feb 2007 15:51:06 -0500
... ... ...
You can also use the -X param. So if I had two different instances of screen running, one of them had sessionname set to FooScreen, I would send a command like:
screen -S FooScreen -X select 1
This would cause screen 1 to be selected within the FooScreen instance.
--
Andy Harrison
From: Michael Schroeder Subject: New screen features available Date: Tue, 6 Feb 2007 23:34:31 +0100 User-agent: Mutt/1.4.2.1i
Hi Screen Users,
you probably wonder why the new version of screen is not already
available. Well, it got delayed a bit because of a couple of new
features I've added. The development version is available from
GNU savanna:
cvs -z3 -d:pserver:address@hidden:/sources/screen co screen
Here are the new features:
- vertical split, complete with resizing
^A | split vertically
resize [-l] [-h] [-v] <amount>
-l : resize is local to slice
-h : resize horizontally
-v : resize vertically
amount: 10 resize to size 10
amount: +10 make 10 bigger
amount: -10 make 10 smaller
amount: 10% make it 10% of all
amount: = make all windows equal
- better resize code using weights
the layout will stay in shape even after heavy resizing
- window groups
currently a bit ugly to create:
screen -t <name> //group
creates a group named <name>
a group is a subset of windows, ^Aw will only display the
current group and next/prev will not leave the group.
Use ^A" to list all windows of the current group (this also
leaves to group, so that next/prev or a second ^A" will
show the other windows.
- layouts
A layout stores the current setup of the display, i.e. all the
slices and the window assignments.
layout save Desktop1
will save the current setup under the name "Desktop1". If you
detach and reattach later on, the layout will automatically
be restored. "Desktop1" will become the current layout.
layout autosave off
This turns the autosafe feature off. Layouts are automatically
saved if autosave is on and the user detachs or switches to
another layout.
layout new Desktop2
Create a new empty layout named "Desktop2".
layout name "foo"
Rename the current layout to "foo".
layout next
layout prev
layout load "name"
Load the next/prev layout / the layout named "name".
layout attach :last
layout attach "name"
Set the layout used when somebody is attaching. Default is ":last",
this is the layout that was current when the last detach was done.
Besides the restoring of the screen on re-attach, layouts can be
used to implement a kind of "virtual desktop" in screen. Say
you put "layout save Desktop1" in your ~/.screenrc. If you
need a new Desktop, do "^A:layout new Desktop2". You can then
use "layout next" to switch between both layouts.
So, feedback welcome. You probably have a lot of suggestions and
enhancement requests. Sorry that development is a bit slow at
the moment due to not enough spare time...
Cheers,
Michael.
--
Michael Schroeder address@hidden
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
This patch provides a vertical split feature for current releases of GNU Screen. The feature is designed to function in the same manner as screen's existing split command, but dividing the regions vertically instead of horizontally. Both forms of splits can be used together in any combination/quantity/order desired. Something similar is slated to appear in GNU Screen 4.1 soon, and is already available in CVS per this mailing list thread (and unofficial Debian packages for a recent CVS snapsho or those interested in trying it out). Also, a recent project named ScreenWM is designed specifically to work with a vsplit-patched screen (check it out!).
The vertical split patch is written and presently under development by
Bill Pursell<bill.pursell@gmail.com> and can be freely used and redistributed under the terms of the GNU General Public License (GPL) version 2.The most recent version of the vertical split patch for GNU Screen can be retrieved via the following link:
As the filename implies, it should patch cleanly into pristine GNU Screen 4.0.2 source (just tested, and works fine with 4.0.3 as well). The MD5 checksum can be obtained via this link:
Screenwm is an extension to GNU Screen that adds (1) multiple region layouts within a single session, (2) vi-like movement within complex layouts, (3) window associations by region, and (4) control of remote/embedded sessions using standard key bindings.
The lines below are numbered for reference. Your config file should not have numbered lines.1 hardstatus alwayslastline 2 hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]' 3 4 # Default screens 5 screen -t shell1 0 6 screen -t shell2 1 7 screen -t server 2Speaking of favorite text editors, there is a good chance that you work on some code projects or configurations. Instead of using gedit/kedit or powering up a heavy IDE such as Eclipse, you can pick up on Vim.... My ~/.screenrc looks like the following:
1 hardstatus alwayslastline 2 hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f %t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %Y-%m-%d %{W}%c %{g}]' 3 4 # Default screens 5 screen -t shell1 0 6 screen -t shell2 1 7 screen -t server 2 sh me@myserver 8 screen -t IRC 7 irssi 9 screen -t Mail 8 mutt
13 July 2007, | polishlinux.org
2. Running programs in the background
Sometimes it would be useful to make screen automatically open a program in its session, give it a name and detach returning to a normal shell, in one command. Use the “-md” options to do this. Combining this with the “-S” option gives some interesting effects:
screen -S ekg_session -md /usr/local/bin/ekg &Screen will create one session, name it “ekg_session”, start the ekg program running inside it and then detach it. Using this method, checking your account on a unix server, you can have either online or “away from the computer” status all the time by one command, while doing other things on the server. Naturally, you can combine many commands into a single command, which makes returning to your work environment easier:
screen -S ekg -md /usr/local/bin/ekg & screen -S mc -md /usr/bin/mc & // screen -S rtorrent -md /usr/bin/rtorrent &This makes screen create three differently named sessions in the background with my favourite terminal programs - ekg, mc and rTorrent.
3. Regions and tabs.
Even though running multiple screen sessions is catered to, its creators give you another choice of how to work. You can run multiple shells within one session! What’s more, you can even display these shells in one terminal window.
But so as not to get lost in these windows, I suggest you create tabs similar to those found in web browsers. You can do this by writing to your configuration file
~/.screenrcone of the following codes:hardstatus alwayslastline hardstatus string '%{= mK}%-Lw%{= KW}%50>%n%f* %t%{= mK} %+Lw%< %{= kG}%-=%D %d %M %Y %c:%s%{-}'or
hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r} (%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'or
hardstatus alwayslastline hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR} (%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}] %{=b C}[ %m/%d %c ]%{W}'With the first code each tab will have a number, a name plus time and date. The second one will give you tabs that will be created in the center and the active tab will be highlighted in red and also have the hostname displayed. The last code will additionally display the processor usage. You can create your own codes but it is a rather specialized task - I refer you to the system manuals for more information.
You already have tabs, now it’s time to create new terminals.
Open a screen session then press
C-a c. A new tab is created. But both tabs have the same title. To change the title of the active tab, pressC-a Aand enter a new name. Creating tabs without a shell but with a program running automatically is a useful feature. The new tab will inherit the name of the program. To use this option pressC-a :and enter the following commandscreen [program name](this is the way you enter all commands during the screen session). To go to the next tab pressC-a nand to return to the previous one pressC-a p. To switch between the tabs useC-a ". This will show you a list of all the tabs.Regions
Regions are a very useful feature. They enable opening many programs and shells in one window of screen. To do it just press
C-a S. The window will split into two separate areas. There will be your actual shell at the top part of the window and the bottom part will be empty. To switch to the bottom part pressC-a [Tab]. You have to create a new shell in the new window, so pressC-a c. You can create more regions by pressingC-a Smore than once and creating new shells in them. Tabs display the active region shellname in its titlebar. You can also switch between tabs being in a region, so e.g: you have 4 tabs and 2 regions. Each region can display one of these tabs. A nice trick is that many regions can display the same tab and they will react simultaneously. It is difficult to describe but is very helpful when you work in multiuser mod and you want to see what another person is doing. You can change the size of each region by enteringresize [size], where size is the number of lines.
Img. 1 Two windows filling whole the display with screen split into two regions4. Configuration file
Previously I mentioned about the configuration file. I wrote that it is in a subdirectory in the home directory named ~/.screenrc. But you can have tens of such files, and when you want to use any of them run screen with the option
-c [filename]. What these files can be? Simply it can contain any of the commands that you usually enter after pressingC-a :. Below I include one of configuration files which causes splitting a window into two regions and running ekg in the top one.
screen ekg— runs ekgtitle ekg— gives title to the windowsplit— splites window into two regions moving ekg to the top onefocus— switches to the bottom regionscreen— runs default shell, in my case it is bashtitle bash— sets title to the bottom regionfocus— switches back to the top oneAs you can see, you can automate a lot of actions which you would do after connecting to a server or running a terminal. A full list of commands can be found in the manual.
5. Logging to file.
To log all the data displayed in a screen session or tab into a file, enter the following command:
logfile [filename]where filename is the name of the file where all the data will be logged. The default name is screenlog.0 (or 1,2,3… if there are more screen shells).flush [seconds]is used to set delay between each write to the logfile, by default it’s 10 seconds.- To start logging enter
log on, to stoplog off.6. The password to screen session.
If there is an important program running in a session you can protect it by using a password. To do this enter
password. Then you will be prompted to type your password twice.After that the hashed password will be displayed. Next you have to copy it to the configuration file after the word “password” in the same line. To cancel the password associated with the session just enter
password nonein the session or delete the line from the configuration file to cancel the password permanently.7. Screen running right after connecting to a remote host.
In fact this tip has not much in common with screen but still I think it is very useful. If you want to run screen right after connecting to a remote host just enter
ssh [username]@[remote host name] -t screen -RD. Unfortunately this command will work only if there is only one screen session running on the remote host. If there is more than one session you have to know its PID or name and use this:ssh [username]@[remote host name] -t screen -R [sessionname/PID]. When you shut down the screen, SSH will automatically log out.8. Locking the display.
To lock the display use the following command
lockscreenor the shortcutC-a x. It doesn’t block the session (like it was in point no. 2), but only “freezes” the display. So detaching and attaching again will cause that you grant the access to session. It can be useful when you are connected to a remote server using the previous tip and you have to go away from the computer. You can’t change the password, because your own user password will be used.9. Comments
I think these tips will be useful for you. I have been using screen for a long time without knowing about such things as regions, tabs and all features I described here.
...I could start a screen session called "radiostation" in this way:
tmancill@ghostrider:~$ screen -S radiostation
(screen blanks)tmancill@ghostrider:~$ mp3blaster
(load my playlist and hit play to start transmitting)
(hit 'Control-a' followed by 'd' to detach)At this point, I can exit my shell, and mp3blaster keeps on running, happily updating the (now non-existent) terminal window with current track information and elapsed time. Let's say that my wife calls me at work and says, "Hey, make this thing play something other than your music." Then, I ssh into ghostrider and resume my session with:
tmancill@ghostrider:~$ screen -r radiostationIf I happen to forget the name of the screen sessions I have running, I can use the "-ls" switch to see what's available:
tmancill@ghostrider:~$ screen –ls
There are screens on:
10238.frm (Detached)
25400.radiostation (Attached)
2 Sockets in /var/run/screen/S-tmancill.If I leave the office without logging out of that "radiostation" screen, I can still resume it by instructing screen to detach (-d) any running session before resuming (-r) the session I'm requesting. In my window at the office, I'll see:
tmancill@ghostrider:~$ screen -r radiostation
[remote detached]Of course, you don't have to be running a radio station to get some use out of screen. It's very useful in a production environment where you don't know from what location you might be needed to access a session. At my office, we needed to run a piece of vendor software underneath GDB in order to be able to produce backtrace information when it segfaulted. When the segfault occurred, our monitoring software would alert us and the on-call member of our support team would produce the backtrace and restart the software. Since any of a number of folks may need to access the session, running the GDB shell on any of our individual workstations was out of the question. One option would have been to run the software directly from the system console, but this meant that the on-call tech had to be onsite and go physically into the data center to perform the reset. So, screen was a natural fit.
Find other admin tips on SearchEnterpriseLinux.com Be cautious about one thing: Screen is sensitive to user permissions, and to users in general. In the GDB example, the vendor software ran under a specific user account, so if you used "su" or "sudo" became another user, you could expect permissions problems. Part of this is that screen needs to be able to open your tty. For example, let's say that I want to run something as the user "asterisk" under screen on my system. If I login in the user "tony" and then become the user "asterisk," I'll run into the following:
asterisk@bach:~$ screen -S pbx
Cannot open your terminal '/dev/pts/146' - please check.asterisk@bach:~$ ls -al /dev/pts/146
crw------- 1 tony tty 136, 146 May 31 18:16 /dev/pts/146As you can see, for the sake of security, my tty is owned by the user who opened the shell, not the effective user ID after I became asterisk. One way around this is to log in directly as the user asterisk before invoking screen. This problem can present itself on the other side as well. That is, if I start the job as asterisk, and log in to a box under another username, and then become asterisk, "screen -r" will still be unable to open the terminal. Also note that before I become the user asterisk, "screen -ls" won't even show me that "pbx" session; appropriately, screen creates a directory for each screen user, and only lists that user's sessions.
How do you get around the permissions problem? If the user account has a password, you can always ssh into the system (probably localhost) directly as that user. Or, if you're in a huge hurry and feel confident that there isn't a local security threat, you can change the permissions on the tty. If you do this, be sure to log out of your terminal as soon as you're done. In effect, you're giving every local system user access to that login shell. Another option is to become root and invoke screen, and then become the system account needed to run the job within the screen session. This will work because the superuser is able to open any user's tty, and (ostensibly) your support staff has sufficient rights to become the root user.
So screen can help you use a large family of terminal software that may not be suited for "unattended" use and yet must be accessible to more than just your initial login session. It's so quick and easy to use that you might prefer it over multiple logins into a remote system, or even over setting up additional virtual consoles on your Linux console. And that's it -- the cereal box guide on a tool that will let you be there when you're not, and still get there when you need to.
One of screen's best features for those who have to remotely adminster machines is its detach function.
You have to log into a remote machine. After logging in, you have to tar and bzip an enormous directory, an operation which will take 45 minutes. Your connection is not the best, and you worry about being disconnected before the operation is complete. However, the remote machine has screen installed.
After logging into the remote machine, your first command is
Begin the tarring and bzipping.
Now detach the screen
you back in the screen where you have been tarring and bzipping the large directory. if it is done, you can type exit, and you will see a message that screen is terminating.If you have several things to do on the remote machine, you might lose track of which screen is doing what. When you log back in you can get a list of your screens with
screen -lsThis returns a list of screens. You might see something like
There are screens on: 6795.ttyp1 (Detached) 26270.ttyp3.server (Detached) 26315.ttyp5.server (Detached) 3 Sockets in /tmp/screens/S-usernameThe trouble with this is remembering which screen is doing what. The first number is the PID. So, if you remember that you used the first screen to tar and bzip a large directory, the second screen to copy some large files and the third screen to do something else, then it's easy. You can type
screen -r 6795and be back at the screen that is tarring and bzipping a file.
If you are going to run several screens, a better way to do this is to start each session with a descriptive name. Say one session will be used for the tar and bzip, another to copy a directory of data and the third session is to copy a large directory of images. Start each session with the -S (as in session name) option and give it a descriptive name. In this case, we'll call them tarbzip, cpdata and cpimage.
screen -S tarbzipBegin the operation, and then detach the screen with C-a d. Now, do the same thing for the other two screens, starting one with screen -S cpdata and the other with screen -S cpimage. Now, if you log back in and want to check your list of screens, doing screen -ls will show something like
6795.tarbzip(Detached) 26270.cpdata (Detached) 26315.cpimage(Detached) 3 Sockets in /tmp/screens/S-usernameSo, as the cpdata screen is probably done already, you first check that one with screen -r cpdata. It makes it much easier to keep track of your screens.
There are plenty of other uses for the detach and reattach feature whether or not you do remote administration.
If you're like me, frequently switching between X and the console, it's handy for starting anything that might take a bit of time, whether it be compiling a large program or chatting on irc with irssi or another client that can be used in console. You can begin a screen session while in console, detach it, start X, open an xterm and reattach the session. Suppose, after logging in, I decided to fetch a large file using ncftp, wget or some other program. Now, I decide I want to do some web browsing with firefox. I can detach the screen session where I've begun the download, fire up X and do my browsing. If I want to check on the download's progress, I can open an xterm, type screen -r and see how it's doing.
This is the sort of handy little thing that makes screen such a convenient program. Are there other ways to do that? Of course. In Unix (and by inference, Linux, the BSDs and any other Unixlike system) there's always more than one way to do something. (The corollary is that someone is sure to think your way is completely wrong.) I could start the download in console, then hit Alt+F2 to open another console. In that console, I could start X
Then, I could hit Ctl+Alt+F1 to return to console. It would bring me to the screen where I started X. I would hit Alt+F1 to bring me back to the console where I was doing the download, check on it, then hit Ctl+Alt+F7 (F9 in FreeBSD) to go back to X. I think using screen is easier.
Screen can also open multiple windows in one console. The usefulness of this is obvious. I'll sometimes use it when installing a system where I haven't yet installed X, or don't plan to install X. Sometimes, I forget syntax and want to check the man page, or perhaps, I have a text based browser installed and want to check a particular web page to remind myself how to do something. With screen, this becomes simple. Rather than having to switch back and forth between consoles, hoping I don't forget what was in the second console, I can split the console window. Then, I can work in the top window and in the bottom one, I can open up w3m (my text based web browser of choice) and go to the web page I need, or perhaps ssh into another machine with a configuration file I want to examine. To do this, open a screen session. Then
C-a Shift+SThe console window will now be split into a top and bottom window. (The S stands for "split".) Your cursor will be in the top window. To move to the bottom window, use C-a and then hit the Tab key. The cursor will now be in the bottom window. Then, C-a and c for command, and you can type in that second window. To move back and forth between the two windows, use C-a and Tab.
You can actually use more than two windows if you wish. While in either of the two windows once again do C-a Shift+S and you will now have three windows. Do it again, and you'll have four windows, but of course, even with a large monitor none of the windows will have more than a few rows. In practice, I seldom use more than two windows in console.
Sometimes, while trying to tab between windows, you'll accidentally hit C-a n or C-a p and suddenly find that the two windows are identical. If this happens, just hit C-a p or C-a n again and you'll find yourself back where you wanted to be. Obvious though this may seem, it can get the newcomer--suddenly, they find themselves with two identical windows on their split screen and not realizing why it happened, they don't know how to get out of it.
To end a split window screen session, simply close them one at a time by typing exit. When you've typed exit in the last window, you'll get the usual message that screen is terminating.
For a program that doesn't seem to do very much, screen is an extremely handy utility. This article only gives the most basic uses of screen. Take a look at the screen man page. You'll see some of the other things it can do.
2. Running programs in the background
Sometimes it would be useful to make screen automatically open a program in its session, give it a name and detach returning to a normal shell, in one command. Use the “-md” options to do this. Combining this with the “-S” option gives some interesting effects:
screen -S ekg_session -md /usr/local/bin/ekg &Screen will create one session, name it “ekg_session”, start the ekg program running inside it and then detach it. Using this method, checking your account on a unix server, you can have either online or “away from the computer” status all the time by one command, while doing other things on the server. Naturally, you can combine many commands into a single command, which makes returning to your work environment easier:
screen -S ekg -md /usr/local/bin/ekg & screen -S mc -md /usr/bin/mc & // screen -S rtorrent -md /usr/bin/rtorrent &This makes screen create three differently named sessions in the background with my favourite terminal programs - ekg, mc and rTorrent.
3. Regions and tabs.
Even though running multiple screen sessions is catered to, its creators give you another choice of how to work. You can run multiple shells within one session! What’s more, you can even display these shells in one terminal window.
But so as not to get lost in these windows, I suggest you create tabs similar to those found in web browsers. You can do this by writing to your configuration file
~/.screenrcone of the following codes:hardstatus alwayslastline hardstatus string '%{= mK}%-Lw%{= KW}%50>%n%f* %t%{= mK} %+Lw%< %{= kG}%-=%D %d %M %Y %c:%s%{-}'or
hardstatus alwayslastline hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r} (%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'or
hardstatus alwayslastline hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR} (%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}] %{=b C}[ %m/%d %c ]%{W}'With the first code each tab will have a number, a name plus time and date. The second one will give you tabs that will be created in the center and the active tab will be highlighted in red and also have the hostname displayed. The last code will additionally display the processor usage. You can create your own codes but it is a rather specialized task - I refer you to the system manuals for more information.
You already have tabs, now it’s time to create new terminals.
Open a screen session then press
C-a c. A new tab is created. But both tabs have the same title. To change the title of the active tab, pressC-a Aand enter a new name. Creating tabs without a shell but with a program running automatically is a useful feature. The new tab will inherit the name of the program. To use this option pressC-a :and enter the following commandscreen [program name](this is the way you enter all commands during the screen session). To go to the next tab pressC-a nand to return to the previous one pressC-a p. To switch between the tabs useC-a ". This will show you a list of all the tabs.Regions
Regions are a very useful feature. They enable opening many programs and shells in one window of screen. To do it just press
C-a S. The window will split into two separate areas. There will be your actual shell at the top part of the window and the bottom part will be empty. To switch to the bottom part pressC-a [Tab]. You have to create a new shell in the new window, so pressC-a c. You can create more regions by pressingC-a Smore than once and creating new shells in them. Tabs display the active region shellname in its titlebar. You can also switch between tabs being in a region, so e.g: you have 4 tabs and 2 regions. Each region can display one of these tabs. A nice trick is that many regions can display the same tab and they will react simultaneously. It is difficult to describe but is very helpful when you work in multiuser mod and you want to see what another person is doing. You can change the size of each region by enteringresize [size], where size is the number of lines.
SCREEN allows you to switch between programs and yet use just one "terminal". So you can write texts, look at emails and newsgroups, read webpages, download files, all at the same time - but with a window for each program. SCREEN shows one window at a time - all other windows are hidden.
SCREEN can permanently show a list of window numbers and their titles in the last line of the terminal. This line can also include other information, eg the hostname, the date or current time.
SCREEN allows to create screendumps so you can easily send bug reports about programs.
SCREEN can also keep a logfile for each window so you can monitor an program and its output.
SCREEN gives you digraph input so you can enter special characters by a combination of two normal characters even when you do not have a suitable keyboard. this makes it transparent for all programs running inside SCREEN.
SCREEN keeps on running even when you log off; programs inside also keep on running. when you log in again you can reattach to your SCREEN session and continue where you left off.
SCREEN also has a builtin lock so you can quickly lock your terminal while you get some more pizza and coke.
SCREEN has a copy mode which allows to copy text from one windows and paste it into another windows - think of "clipboard". the contents of the clipboard can also be written to a file and read from it, too. you can exchange data between your own session and another user's session on the same host that way. Each window has a backlog for scrolled off lines which can be accessed for copying, too.
SCREEN can monitor the invisible windows for action or silence and inform you about it. Very useful with chatting or compile sessions.
SCREEN let you set (read/write) permissions for other users so other people can watch your session or can even write to your processes and thus you can use SCREEN for collaboration on some work. Admins can see what their users are typing and therefore help them out much better.
SCREEN runs on almost all kinds of Unix (and FreeBSD and Linux, of course).
There is no GUI required - you simply have to have a connection to a machine which has SCREEN installed.
SCREEN works on a simple "telnet" session - but we recommend using terminal emulators which make use of encrypted data transmission, using the ssh protocol.
SCREEN has free key binding and is Free Software! :-)
(see eg my page on terminal emulators for Windows).Summary: Start SCREEN before starting any other commands. It'll be well worth it.
- Window Multiplexing
- SCREEN allows you to switch between several windows, each running its own program. This allows you to use several programs at the same time, such as a mailer, a newsreader, a webbrowser, an editor, and a shell. All of this on the same terminal - no more required.
- Using only one terminal is also nice as you can share the console windows on the same FreeBSD or Linux machine with others. One console window for each user - that's all you need. And there is no need to remember which consoles are taken and which ones you still need to log out from. ;-) Furthermore, you only need to lock your console once to lock your whole SCREEN session. (see below)
- Window Backlog, Hardcopy and Logging
- SCREEN allows you to make a hardcopy of a window (aka "screen shot"), and it automatically saves everything that "scrolls off" your windows into a "backlog" (the length is configurable in the setup file). SCREEN also allows keep a "logfile" for a window which is very useful for programs that do not have a logfile feature.
- Copy&Paste
- SCREEN gives you "copy&paste", ie commands to copy text from a window and its backlog; the copied text can then be pasted into another window or into a temporary file for exchange with programs and user of SCREEN.
- Key Binding
- SCREEN lets you "bind" keys to commands to abbreviate tasks.
- Session Detaching and Reattaching
- SCREEN lets you "detach" a session, ie ite keeps running without a terminal.
- Usually programs that send their output to a terminal will die as soon as the (connection to the) terminal is gone. But when SCREEN is detached the started programs will keep on running. This allows you to keep programs running while you are away (ie you log out, abandoning your terminal). No need to start all the programs again - just reattach to your (running) SCREEN session! So whether you lose your connection to the host running your SCREEN session by accident or whether you detach your session and log off - as soon as you reattach to your session you can continue your work.
- Session Locking
- You can "lock" your session so that others cannot use it. You can either use the built-in lock program or select your own one. For the built-in lock program you can either have the lock unlocked with your current password on that machine or you can set a separate password for SCREEN sessions only by adding a (crypted) one to your setup file. (see below)
- Useful if you just leave the computer console for a short time, eg when you leave the room to get a printout or when get yourself something a drink, or when you need to get rid of just those. ;-)
But for a more complete text on SCREEN's features please have a look at the Intro. just try the commands and get a hands-on experience.
SessionsNow that you're creating new windows and bouncing around between them, you can get many things going in parallel. You could potentially have some editors, an IRC client and a few other things all running in their own windows. But occasionally disaster strikes, and your network connection dies (those of you still playing along at home can kill your SSH client). It looks like it's time to pick up the pieces and relaunch all of your applications on the remote machine, right? Not with screen.
Each time you start up screen without arguments, it creates a new session. This spawns two processes: a terminal management process and a client process. The client process automatically is ``attached'' to the terminal management process. When you type, the characters you enter go to the client, which sends them to the terminal management process, which then sends them to your application.
When your network connection dies, the client catches the signal and detaches from the terminal management process. The terminal management process continues along managing your terminals as if nothing happened. When you log back in, you can list running sessions by issuing screen -ls at the prompt. It should show something similar to the following:
There are screens on: 24319.pts-9.hostname (Detached) 1 Sockets in /var/run/screen/S-youruserid.This shows that your session automatically detached when your connection dropped.
You can re-attach to the session in a few ways. You can give a session name explicitly with screen -r sessionname. You can tell it to re-attach if possible, otherwise start a new session by running screen -R. Or you can go the ``do whatever is needed to get a screen session'' route and run screen -D -RR. This last option will detach already-attached clients and attach to the first session listed.
When you run one of these commands, you should be right where you left off before your network connection went down. When you're re-attached, you can continue working as if nothing ever happened.
It is also possible to attach to a session multiple times. This is useful if you haven't closed your screen session from another machine, or if you simply want to display windows from the same session side by side. You can multi-attach by adding an -x in the command-line options to screen when attaching.
Finally, when the end of the day rolls around and it's time to go home, you can detach from your session using Ctrl-A D. When you return the next day, you can re-attach, and you will be back where you left off.
Copy and Paste/Scrollback ModeOne of the key features listed in the beginning of the article was screen's searchable scrollback. This is a feature I could not live without. It's not immediately obvious to the new screen user, but screen's scrollback is accessed via the copy command. (You can enter copy mode with Ctrl-A [ or via the copy command.) Navigation works as expected with either the Arrow keys and Page Up/Down or the vi motion equivalents. Searching is accessed via either / and ? for vi-style search or Ctrl-S and Ctrl-R for incremental search. Case-insensitive search can be turned on with the screen command ignorecase yes. If you are using copy mode for scrollback only, it can be exited at any time with the Esc key.
To copy text, maneuver the cursor to the beginning of the desired text, and press the spacebar to mark it. Then position the cursor over the end of the text you'd like and press the spacebar again to mark it. When you mark the end, the text is copied into screen's internal copy buffer, and copy mode is exited. You can paste the text in your copy buffer into the active window with Ctrl-A ].
The final thing you should know about the copy and paste mode is the scrollback buffer is limited to 100 lines by default. This is, in my opinion, not enough. You can tweak this to a higher value (1,024 for example) by adding the command defscrollback 1024 to your .screenrc.
Opening Windows with screenrcI have already mentioned that you can add a command to your .screenrc to change the behavior of screen. It's not immediately obvious, but you can put any screen command in a screenrc. This is very useful and can be used to spawn windows automatically with the screen command.
A typical application of this tidbit of knowledge is to launch a predefined set of windows at screen startup. Below is a sample screenrc that will do so:
# read in your normal screenrc # before anything else source $HOME/.screenrc # now start opening windows screen top # it's possible to set the window title with # the -t option screen -t irc epic # you can also specify the window number # to launch in screen -t mail 8 mutt screen -t daemon 9 tail -f /var/log/daemon.logIf you save this to $HOME/.screenrc.multiwin you can tell screen to use it instead of your normal .screenrc by running screen -c $HOME/.screenrc.multiwin.
You also can launch more systems-oriented screen sessions from a startup script. A common application of a system screen session is a serial console server. Screen is well suited for this task because it has built-in support for serial terminals and logging. A commented example of a screenrc for this purpose is:
# This assumes that serialuser has proper # permissions to access the serial ports and to # write to the log files specified in the screenrc. # turn logging on for all windows deflog on # tell screen to log to /var/log/serial.$WINDOW logfile /var/log/serial.%n # open windows on the serial ports screen /dev/ttyS0 38400 screen /dev/ttyS1 19200If you saved this file in /etc/screenrc.serial, you could launch it at startup with a script that runs:
su serialuser -c \ 'screen -dmS serial -c /etc/screenrc.serial'The -dmS serial options tell screen to launch the session in detached mode and name the session ``serial''. User serialuser can log in and attach to this session exactly like any other normal screen session. Launching a detached screen also can be used to start screen from a cron job if this is preferred.
It is possible to set up a single system-wide screenrc that allows multiple users to connect to it. Screen supports multi-user mode with per-window ACLs that define what each user can and cannot do. Multi-user screen sessions, however, require that screen be setuid root. Because of this requirement, I am not going to include examples for multi-user screen sessions in an introductory article. If you would like to set up a multi-user screen session, read the screen docs, put on your ``adding setuid root permissions to a complex piece of code'' paranoia hat and be prepared to lock things down as tightly as possible.As a third application, you could merge the two previous examples and launch system-wide interactive programs via screenrc. A good use of this would be launching mutella, a curses-based gnutella client, at startup. With screen, you can launch this program and connect to it on occasion to see the status, run queries, etc.
[»] Fix for backspace problem on some systems
by devel at hastek - Sep 25th 2003 23:49:59I am only posting this because I didn't find the answer readily in the archives or elsewhere.
The key bindings have always been fine under Linux, under Freebsd 4.x using bash, the backspace key is not mapped to "erase". I ended up with
bindkey -d -k kb stuff "\010"
in my .screenrc and it seems to work fine.
This didn't work until I put the quotes around the character code. Perhaps this would be a useful example in the manpage?
-Harold
emad:Screen's awesome...it solves the biggest problem I had with Putty, namely that any more than 4 Putty windows and life becomes a hodge-podge of small windows that need to be precisely positioned for optimal use. Doesn't help that Putty can't store positioning info, so I have to spend 5 minutes every time I reboot to arrange my windows pixel-perfectly :)As for your logging problem, have you tried ctrl+a, ctrl + H? That'll create a log file that all screen output is sent to, typically $HOME/screenlog.${VIRTUAL_SCREEN_INDEX}.
Thanks for the comments, they're appreciated. :)
Another nice (and sometimes overlooked) feature of Screen that I neglected to mention is copying and pasting...
When you have text you want to copy to Screen's "clipboard" buffer, simply press
CTRL-A [
And you will go into Copy Mode. From here you can use standard vi cursor movement keys (left, down, up, right arrow keys, and h, j, k and l respectively) to move the cursor around to the beginning of what you want to copy. Press RETURN at your starting point, move the cursor to the end of what you want to copy, and press RETURN again.
Then, to paste your newly copied text, press
CTRL-A ]
And screen pastes your text for you. No mouse necessary.
Cheers,
SamPosted by Sam Foster @ 04/22/2004 05:02 PM CST
Ah ha! This page got me moving in the right direction, but I want to clarify Sanjay's points about sharing screen between multiple users.
First of all, in screen you have to hit C^a and then the colon (":") key to enter commands (much like vi). when you do that, you'll see a highlighted colon prompt at the bottom of the screen. Then turn on multiuser and grant permissions like Sanjay said.
Second, you may have to do some other things. I installed screen with the Debian package, and multiuser mode didn't work out of the box. You could add people to the acl list, but when you did:
screen -ls otheruser/
you'd get the error:
Must run suid root for multiuser support.To make screen run as suid root, as the root user do:
chmod +s /usr/bin/screen
(or whatever the path to your screen executable is)There is also a command called aclgrp, whereby you can assigna group of users similar access to screen. Note that this doesn't mean you can automatically give everyone in a particular Unix group access to a screen session, though. I might work on a little script to do that. If I figure it out, I'll post it here.
Thanks Sam and Sanjay!
Posted by Ben @ 03/03/2004 11:40 PM CST
good intro and show up high in google SERPs
Posted by Sam Lowry @ 02/05/2004 03:32 AM CST
Thanks !.
You may also want to include acladd and aclchg commands which will tell you how to share a session between different users.e.g. if user1 is running screen and you want to share it with user2.
Here are few things which you will do:
in user1 screen
C^a multiuser on
C^a acladd user2Now from user2 session :
To list available screens :-
screen -ls user1/
to attach :-
screen -r user1/pid
Note you can also use aclchg command to control permissions for screen session
Posted by Sanjay @ 01/14/2004 02:22 PM CST
In general, screen commands are accessed by typing "CTRL-a" followed by a keystroke. The following gives a summary of screen commands for basic navigation.
CTRL-a c Create a new window CTRL-a spacebar Go to next window CTRL-a backspace or del Go to previous window CTRL-a 2 Go to window 2 CTRL-a w list windows To exit a window, just exit from the shell in that window, and the window is killed.
It is possible to "detatch" a session. In this case, the session is running independent of your login window, and when you exit your login window, the session contiues to run. When you relogin later, you "re-attatch" the session to your new login window. The following commands are relevant.
screen -d -r reattach a session, and if neccessary, detatch it first screen -d detatch session from terminal screen -list show status Sometimes your screen may appear to freeze. You know the connection is still good, but key strokes do nothing. The problem is that you accidently pressed Ctrl-S, which causes the terminal window to stop. To exit the stopped state, you need to press Ctrl-Q.
Common Screen Tasks
Starting and Selecting Windows
Once screen is installed, it can be used without any further configuration. First run
/usr/local/bin/screento start a session. As mentioned previously, this starts one virtual shell window. Generally, additional shell windows are desirable and can be started with the prefix key followed by Ctrl-c,Ctrl-a Ctrl-c. This runs the screen commandscreen. Additional windows can also be run by entering screen's command mode and entering the command there. The command mode is entered by the key sequenceCtrl-a :. Once in command mode, type inscreenand hit return. Every command that can be run by entering a key sequence can also be run by name from screen's command mode.In addition to shell windows, screen can also attach directly to serial devices. This is quite useful when installed on a machine acting as a console server to a number of other machines or on a machine directly attached to a modem. To attach directly to /dev/ttyb, for example, enter command mode and give the screen command port as an argument:
Ctrl-a : screen /dev/ttyb. This is shorthand forCtrl-a : screen cu -l /dev/ttyb.Once a screen session has multiple virtual windows, the user needs to easily switch between them. Like a TV remote, screen can access windows by using a wraparound
previous/nextmechanism or by specifying the window directly. Each window has an associated number, which gives it its place in the ring. To obtain information about all windows, enter the key sequenceCtrl-a. To obtain information about the current window,Ctrl-a i.To switch to the next window in sequence, enter the key sequence
Ctrl-a Ctrl-n, and to switch to the previous numbered window,Ctrl-a Ctrl-p. To hop directly to a window, enter the key sequenceCtrl-a #where#is the number of the window. For example, if there were a shell running in window 2, switch to it usingCtrl-a 2. To see a listing of all virtual windows and select one to switch to, enterCtrl-a ". To hop back to the window last displayed, enterCtrl-a Ctrl-a.
History, Cut and Paste, Logging, and MonitoringWhen the user is working on a terminal that has no mouse, screen offers the capability to cut and paste by using a virtual clipboard. The key sequence
Ctrl-a Ctrl-[enters copy/history scrollback mode and allows the use of (mostly) vi-style syntax to navigate through the scrollback buffer. The motion options available in copy/history scrollback mode are covered in detail in the man page. The copy range is specified by setting two marks. The text between these marks will be highlighted and stored into the paste buffer. Press the space bar to set the first and second marks, respectively. To paste the text just saved to the buffer, go to the appropriate location in the desired window and enter the key sequenceCtrl-a Ctrl-].Activity in a screen virtual window can be logged to a file, much like the UNIX
scriptcommand does for an interactive session. To toggle logging of activity in the window to the filescreenlog.#, where # is a number starting at 0, enter the key sequenceCtrl-a H. Along the same lines, a window can be watched for any activity. If the user is in window 3 and activity occurs in window 2, a message will be displayed at the bottom of the screen session if window 2 is being monitored. To toggle monitoring of the current window on the fly, use the key sequenceCtrl-a M.
Locking and Detaching, and Reattaching
Perhaps the two most useful features of screen are the ability to lock the terminal and the ability to disconnect the session and later reconnect. To lock the terminal (or xterm, if called from one), enter the key sequence
Ctrl-a Ctrl-x. This runs /usr/bin/lock or an internal function and does not pass any input to the screen session from that terminal until the user's password is entered correctly. Processes in each window continue to run just as if the screen session were detached.There are two ways to detach a screen session, power detach and a regular detach. In a regular detach (
Ctrl-a Ctrl-d), the screen session is detached and the user is returned to the shell from which screen was invoked. In a power detach (Ctrl-a D D), the screen session is detached and the user is logged out of the calling shell. The user can also kill all windows and terminate screen instead of detaching by entering the key sequenceCtrl-a Ctrl-\.Screen sessions can also be detached from outside the screen session, which is useful for stealing a session after changing physical locations. Again, sessions can be detached regularly or power detached, but if a user runs more than one screen session, the correct session to detach must first be determined. This is done by issuing
screen -lsfrom the command line. On a machine calledhostnamewhere the userusernameis attached to two sessions, the output of the aforementioned command will look like:% screen -ls There are screens on: 651.pts-5.hostname (Attached) 16405.pts-12.hostname (Attached) 2 Sockets in /tmp/screens/S-username.To detach the session
651.pts-5.hostnamerun one of the following commands, the first being a regular detach and the second being a power detach:screen -d 651.pts-5.hostname screen -D 651.pts-5.hostnameIf there was only one active session, screen could be called without the session name:
screen -d screen -DThere are a variety of ways to reattach to a detached session, some of which will even detach the session first if needed. Each of the following is a command-line option to the
screenprogram:
- -r [pid.tty.host]: Reattach a detached session, optionally specifying which session.
- -r sessionowner/[pid.tty.host]: Attach to another user's session running in multiuser mode. This argument requires that screen be installed SUID root and indicates that screen should look for sessions in another user's screen directory.
- -R: Reattach to the first detached screen session found. If no detached session exists, this starts a new session using any additionally specified options. If a reattach is instead successful, all other command-line options are ignored.
- -d -r: Reattach a session and if necessary detach it first.
- -d -R: Reattach a session and if necessary detach or create it first.
- -d -RR: Reattach a session and if necessary detach or create it first. Use the first session if more than one session is available.
- -D -r: Reattach a session. If necessary power detach first.
- -D -R: If a session is running, then reattach, power detaching first if necessary. If a session was not already running, create one and notify the user.
- -D -RR: If the first session found is running, then reattach, power detaching the first if necessary. If a session was not already running, create one and notify the user.
- -x: Attach to an already attached screen session. (Multi-display mode).
When a screen session dies, either because the machine rebooted or the process got killed or corrupted, the dead socket file can be left in the screen directory. A dead screen session cannot be reattached, and the sockets should be cleaned up. These dead screens are visible with the
screen -lscommand and can be cleaned out with thescreen -wipecommand.Customizing Screen
Screen can be effectively run without any configuration at all, but most sysadmins will want to change some default behaviors and create shortcuts with key bindings. Most customization occurs via the screen resource files, though sessions can also be customized from the invoking command line or on the fly. Directives in the resource files set options, bind functions to keys, and automatically start virtual windows at the beginning of the session. Each directive is listed one per line with the arguments separated by tabs or spaces. The pound sign (#) acts as the comment delimiter, and any text appearing on a line after one is ignored. Any blank lines in the file are ignored. The arguments section of each directive can contain references to environment variables as well as plain text.
Here's a short example $HOME/.screenrc file containing comments for each directive:
# set some options activity "activity: window ~%" # Message when activity occurs in a window vbell_msg "bell: window ~%" # Message for visual bell vbellwait 2 # Seconds to pause the screen for visual bell allpartial off # Refresh entire screen on window change autodetach on # Autodetach session on hangup instead of # terminating screen completely bufferfile /tmp/screen-buffer # Filename for the paste buffer chdir # Change to the home directory escape "``" # Redefine the prefix key to ` and define a # literal ` as `` shelltitle $HOST # Set the title of all shell windows defflow off # Set the default flow control mode defmode 0620 # Set the default mode of each pseudo tty defscrollback 200 # Set the default number of scrollback lines deflogin off # Do not register the window in utmp startup_message off # Disable startup messages # virtual windows to start when screen starts screen -t emacs@$HOST -h 0 1 /usr/local/bin/emacs -nw # Start emacs in window 1 with a scrollback # buffer of 0 screen -t tcsh@$HOST -ln -h 100 2 # Start a shell with the title of # tcsh@. turn off login mode # (remove the window from utmp). Use a # scrollback of 100 lines and start the shell # in window 2 (or the next available window) monitor on # Monitor the above shell window # keymap for use with the prefix key (backquote) bind ' ' windows # Show listing of all windows bind 'a' prev # Previous window bind 'c' copy # Copy paste buffer bind 'e' screen -t emacs@$HOST -h 0 1 /usr/local/bin/emacs -nw # Create new emacs window bind 'i' info # Show info about the current window bind 'n' next # Next window bind 's' screen -t tcsh@$HOST -ln -h 100 # Create new shell window As shown above, one very common modification is changing the prefix key from
Ctrl-a(used in emacs to go to the beginning of the line) to something less frequently used. Picking an alternate prefix key can be difficult if the user makes full use of all of the keys; the alternate is usually a seldom-used combination involving the escape or control key. This makes for extra typing, of course, so one-key prefixes are optimal if the prefix key sees a lot of use.Resources
The
screen(1)man page contains a wealth of information for the power-user as well as the novice. It lists the defaults for the large number of customizable options, key bindings, and command-line arguments, as well as providing a few examples. Other resources include:
- The screen home page
- GNU mirror sites
- The screen mailing list archive
Many of us use the excellent OpenSSH as a secure, encrypted replacement for the venerable telnet and rsh commands. One of OpenSSH's (and the commercial SSH2's) intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based upon a pair of complementary numerical "keys". And one of the main appeals of RSA and DSA authentication is the promise of being able to establish connections to remote systems without supplying a password. The keychain script makes handling RSA and DSA keys both convenient and secure. It acts as a front-end to ssh-agent, allowing you to easily have one long-running ssh-agent process per system, rather than per login session. This dramatically reduces the number of times you need to enter your passphrase from once per new login session to once every time your local machine is rebooted.
Keychain was first introduced in a series of IBM developerWorks articles.
- The first article introduces the concepts behind RSA/DSA key authentication and shows you how to set up primitive (with passphrase) RSA/DSA authentication.
- The second article shows you how to use keychain to set up secure, passwordless ssh access in an extremely convenient way. keychain also provides a clean, secure way for cron jobs to take advantage of RSA/DSA keys without having to use insecure unencrypted private keys.
- The third article shows you how to use ssh-agent's authentication forwarding mechanism.
Current versions of keychain are known to run on Linux, BSD, Cygwin, Tru64 UNIX, HP-UX, Mac OS X, and Solaris using whatever variant of Bourne shell you have available.
A: The way I do this (in tcsh) is that I set my prompt string to modify screen's hardstatus line (this will be mapped to xterm's title bar). Here are the corresponding lines from my .cshrc:
if ($TERM == screen) then
set prompt="%{ESC_#$WINDOW %m:%c3ESC\\%}%h (%m:%.)%# "
else
set prompt="%h (%m:%.)%# "
endif
(Note that ESC means a real ESC (octal 033) chars).
GNU Screen has a copy/paste facility without using a mouse. It has screen dump facility, history mechanism and so on. This comes as a great boon to command line junkies like me.
It can be locked easily and detached and re attached at will. Either as a multi display mode or single display.
And it displays what you want it to show in the status line on the bottom of the screen. For instance, my ~/.screenrc has
shell -${SHELL} caption always "%n(%t) : %C"This displays the screen number, the title in brackets and the current time. I find this adequate for my needs. You can write one to suit your taste.
GNU Screen and OpenSSH are two incredibly useful tools. In this tutorial, I hope to help users to work around a small, but annoying, problem that can arise when using SSH-Agent forwarding and Screen. This tutorial assumes you have knowledge of SSH, SSH-Agent, SSH-Agent-forwarding and GNU Screen. I also assume you're using a shell that can handle Bourne shell variable syntax.
The Problem
SSH-Agent forwarding breaks when screen is re-attached on a different host.
Details
The problem involves three hosts
* , A, B, and S. All of these hosts have Agent-Forwarding enabled in their SSH configuration.I log into host A and run ssh-agent, authenticating to my key. I connect from machine A to machine S using my agent/key to authenticate. On machine S, I start screen. I open several screen windows, all running shells. These shells inherit the ssh-agent variables from the parent shell that spawned the screen. (This is where the problem starts.)
I notice that it's time for work, so I drive to work and log into machine B, starting ssh-agent and authenticate to my key. I connect from machine B to machine S using my agent/key to authenticate. I resume the running screen that I started when logged in from machine A. Naturally, all of the ssh environment variables are still set the way they were prior to the screen de/re-attach. So now, despite having ssh-agent forwarding turned on and having an active agent, I can't connect to remote hosts via host S without some kind of magic.
* This problem could also involve two connections from the same host (which will be on different client ports,) to a second host. I think the above example is clearer.SSH Environment Variables
When you connect, using ssh-agent for authentication, to a host that has ssh-agent forwarding enabled, the following shell variables will be set:
SSH_CLIENT=192.168.25.198 4671 22 SSH_TTY=/dev/pts/11 SSH_AUTH_SOCK=/tmp/ssh-zIn16635/agent.16635 SSH_CONNECTION=192.168.25.198 4671 192.168.25.3 22The SSH_CLIENT variable contains three space-separated pieces of information. The IP address of the client making the connection, the client's port number, and the server's port number.
The SSH_TTY variable is set to the path to the tty device used for the shell opened when the SSH connection was created.
The SSH_AUTH_SOCK variable identifies the path of a unix-domain socket used to communicate with the agent. In other words, this variable sets up a "path" back to the host that is actually running the agent, so that future ssh connections can talk to/use that agent.
The SSH_CONNECTION variable contains four space-separated pieces of information. The IP address of the client, the port number of the client, the IP address of the server and the port number of the server. This variable is necessary to prevent agent hijacking.
So, now that I've reiterated the ssh(1) man page, we can see why, when we connect from A to S, and then from B to S, ssh-agent forwarding fails. In the initial connection, S defines the SSH environment variables to point to host A. When screen starts its shells, they inherit those variables. When host B connects and grabs that instance of screen, the sub-shells have no idea that anything has changed, so the variables now point to the "wrong" machine.
The Solution
The environment variables listed above are set correctly when host B connects to host S, so we need a way to get them propagated to the shells running inside screen. I wrote a small script to cull them out and stick them in a file. The script also re-formats them so that they will be easily integrated into the shell's environment. I called this script "grabssh."
#!/bin/sh SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY" for x in ${SSHVARS} ; do (eval echo $x=\$$x) | sed 's/=/="/ s/$/"/ s/^/export /' done 1>$HOME/bin/fixsshThe output of this script looks something like this:
export SSH_CLIENT="192.168.25.198 4685 22" export SSH_TTY="/dev/pts/22" export SSH_AUTH_SOCK="/tmp/ssh-jtF17289/agent.17289" export SSH_CONNECTION="192.168.25.198 4685 192.168.25.3 22"Rather than having to type in "grabssh" before resuming any screen, I created an alias:
alias Attach='grabssh ; screen -d -R'So now every time I resume my screen, the correct ssh-agent variables will be written to ${HOME}/bin/fixssh. I wrote another alias to source that file:
alias fixssh='source $HOME/bin/fixssh'Now, when I'm in a screen-spawned shell and I want to take advantage of ssh-agent forwarding, I run "fixssh" and everything just works. You might even go so far as to create an alias for ssh like this:
alias ssh='fixssh; ssh'However, that alias might someday drive you insane if you're troubleshooting some ssh problem and you forget that it is there.
Send comments to Sam Rowe, deadman at deadman dot org
This article first appeared when I wrote it for Kuro5hin. If you want to read the original version of the article with comments containing some useful Screen tips and tricks, here is the original, archived article at Kuro5hin.
Most modern Unix-based operating systems (e.g. Linux, MacOS X, and BSD) come with a little console-mode utility called GNU Screen. It's a powerful tool in the hands of the console warrior, a veritable Swiss Army knife of text-mode human-computer interaction.
This utility, despite its considerable usefulness, goes unused by a great many people. Why is this? Few people even know it's there, and those that do rarely understand the problem it solves. In this article, I will explain what screen does for you, and provide a simple set of instructions for accomplishing basic tasks using screen. My audience is those that are skilled with the command line but who have little or no experience with screen itself.
- What screen does. Screen is best described as a terminal multiplexer. Using it, you can run any number of console-based applications--interactive command shells, curses-based applications, text editors, etc.--within a single terminal. The desire to do this is what gets most people hooked on screen. I used to start a half-dozen terminal emulators when I logged into my machine: I wanted one to read my email, one to edit my code, one to compile my code, one for my newsreader, one for a shell into my web host, and so on. Now I start one terminal emulator, and run screen in it. Problem solved.
The other main cool feature of screen is its ability to decouple the terminal emulator from the running programs. This means that you can use screen to keep programs running after you accidentally close the terminal emulator, or even after you log out, and later resume right where you were. It means that the idea of a "session" in which you are running a number of console programs is a free-floating entity that you can bind to any terminal anywhere, or no terminal at all if you want.
- Getting started with screen: launching and switching between programs. Start screen just by typing screen at your favorite command shell prompt. You'll probably be greeted by a welcome message. Dismiss this and you'll have an empty terminal containing a shell prompt, which is pretty much what you had before you started screen. What happened?
Every program running under screen runs in a window, and every window is identified by a unique number. Screen made a new window, numbered it 0, and started a command shell inside it. Type something in your new window so you'll be able to recognize it when you switch to it later.
Now make another window; this will be window 1. To do this, type Ctrl-a c; that is, type Ctrl-a and then type c (mnemonic: create window).
Now that you have two windows, try switching between them. To do this, type Ctrl-a Ctrl-a, which will switch you to whichever window you were using before the current one. Some other useful window switching methods, which you'll need if you plan to run more than two programs:
Use Ctrl-a n and Ctrl-a p to switch to the next or previous window in the list, by number.Use Ctrl-a N, where N is a number from 0 to 9, to switch to the corresponding window.
Use Ctrl-a " to get a full-screen list of windows. You can navigate this list with the arrow keys (or vi-style, with j and k), and pick a window to activate by pressing Enter when it's highlighted. Ctrl-a w will give you a small, non-interactive list of windows.
- Detaching and reattaching: the magic of terminal decoupling
If you did the exercise above, you have successfully created a screen session. You can detach from this session by pressing Ctrl-a d. You can also detach just by closing the terminal emulator that contains the session. However, keep in mind that neither of these actually end your session. All they do is unbind your session from the current terminal. All of the programs you started running within screen are still running.
To reattach type screen -r (the R, obviously, stands for "reattach"). You'll be right back where you were when you detached.
You can probably imagine a lot of good uses for this. You can start all your favorite console programs once and just leave them running in a persistent screen session. Some people have "screen uptimes" of several months.
One other good use for the detach and reattach is as a console-mode "remote desktop" feature. You can detach from a screen session at work, shell into the machine from home, and reattach. Very, very handy. With a bit of extra work, you can even have a number of terminals all attached to the same session--great for collaborative efforts and meetings.
- Copying, pasting, and the scrollback buffer
Screen remembers a configurable number of scrollback lines, and you'll need them because you won't be able to use your terminal emulator's scroll features while running screen. You can access the scrollback buffer by entering "copy mode", which is accomplished by typing Ctrl-a [. You can mark text anywhere in the scrollback buffer and paste it with Ctrl-a ]. Screen is also capable of logging to files, but that's beyond the scope of this tutorial.
- Monitoring for silence and activity
One of the disadvantages of running a bunch of programs within screen is that you can't keep an eye on all of them at the same time, since in general you can only see one at once. (Actually, you can split the screen and look at more than one at a time, but that's an advanced topic beyond the scope of this tutorial.) To help mitigate this problem, Screen has features that allow you to monitor a window for silence--useful for knowing when a compile has finished, for example--or activity--useful for knowing when someone is finally talking on your favorite IRC channel, for example.
To start or stop monitoring the current window for 30 seconds of silence, type Ctrl-a _; to start or stop monitoring a window for activity, type Ctrl-a M.
- Making it go away
As you've seen from the section on detaching and reattaching, screen is not easy to kill. You can't just close its containing terminal. (Actually, you can, but then all those processes are still running on your system, ready to be reattached.)
To my knowledge, the only way to do this nicely (i.e. without sending nasty signals to processes that don't deserve it) is to close each of your screen windows. Exit whatever programs or shells each is running, and they will go away. When the last program running inside screen is exited, screen itself will go away. You can forcefully quit screen with Ctrl-a Ctrl-\, but I wouldn't recommend it.
- Other stuff
Screen does much, much more than I've described above, but it's enough to get you started. You can type Ctrl-a ? for a terse list of commands available while you're in screen. The screen man page has a wealth of info, too. And here are some web resources, if you have questions.
Most people who do lots of work in a Linux terminal use GNU screen (tabbed terminals are for chumps.) If you're not familiar, it works like this: type screen. Type ctrl-a, c to create a new window. Type ctrl-a, p to go to the previous window, and ctrl-a, n to go to the next. Voila.
Not only does it give you the ability to multiplex many windows inside of one terminal, you can "detach" and "reattach" the screen session. So, you ssh to your server somewhere, and open up a bunch of windows doing various things. Then, you decide to go drink beer at the pub, who just happens to have wireless, so you ssh from your laptop to the server, and reattach. Voila again. You're back working where you were, and you didn't have to quit everything you were doing and set it back up again later. A lot of people use this for irc, to avoid quitting and rejoining the network frequently. But it's useful for any interactive shells you'd like to pick back up later, possibly from a new location.
Whether you're already familiar with screen or just learning about it, here's a cool tip. Put the following in your ~/.screenrc:hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%D %M %d %c" hardstatus string '%{= kK}%-Lw%{= KW}%50>%n%f %t%{= kK}%+Lw%< %{=kG}%-= %d%M %c:%s%{-}'You can fiddle around with the control codes to change the colors, if you'd like. See the screen man-page for info on that.
This will give you a screen status line at the bottom of your terminal, showing the names of all your virtual windows, which one was previously active (for ctrl-a, ctrl-a flipping), and will show the currently active window name. This is really handy, especially if you're like me and have anywhere from 5 to 30 windows open in various screen sessions.
Here's my full screenrc:# eater's elite .screenrc shelltitle '' vbell on autodetach on startup_message off defscrollback 2048 hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%D %M %d %c" hardstatus string '%{= kK}%-Lw%{= KW}%50>%n%f %t%{= kK}%+Lw%< %{=kG}%-= %d%M %c:%s%{-}'
The shelltitle is important. Otherwise all new windows will display a default title of "bash" (usually) and clutter up your elite new status bar. You can rename a window using ctrl-a, A.
With these additions, my status bar looks something like this:
0$ efnet 1$ svn 2$ foo.pl 3-$ blog.txt
"efnet" is the current because it's hilighted. "blog.txt" was the previous window because it's marked with the "-", so I can type ctrl-a, ctrl-a to flip back to it easily. If I want to change to "foo.pl", I can type ctrl-a, 2.
This makes it very easy to transition between many different windows, without the overhead of alternative approaches like tabbed-terminals or multiple instances of your terminal emulator.
Eater. Saturday, June 10, 2006
Updated 13 Sep 04. Nevermind. phil_g's comment says it well. keychain is the way to go. I'll rewrite this when I have more time.Some co-workers turned me on to GNU screen last year. It's a handy addition to my toolbox. It became most useful after I learned how to use it with SSH. The original URL that gave me the solution appears to be gone (a message in the now-defunct gnu-screen Yahoo group). So I thought I'd write this up and see how it fares when people google gnu screen ssh.
The solution I settled on is a nested invocation I learned from Jason White. I recommend you read my screenrc and my slave screenrc in another window and read along here for commentary. You run an "outer" screen session (the "slave" session) that in turn runs an "inner" (or "master") session. You use the regular escape sequence (Ctrl-A d) to detatch from the master, and you map Ctrl-^ to be the control key for the slave session. If you press Ctrl-^ while using screen this way, you'll see one process in the slave session. It's running ssh-agent. That's the key to using ssh with screen. The slave's only purpose is to run ssh-agent. The master runs as a child of that. Consequently, all shells in the master session are running under the ssh-agent. Just run ssh-add from any master shell, and then all shells have your ssh identity.
For more information about GNU screen, see GNU Screen: an introduction and beginner's tutorial or Power Sessions with Screen. For more information about SSH, see openssh.com.
Nested Screens Not Necessary
phil_g
2004-07-06 08:57 am UTC (link)You don't need to use nested screens to get this effect. I achieve it by the use of a simple wrapper script for screen. To attach to a screen session, I have a single script that I run; it loads the agent before starting screen. (I use keychain to ensure that only one agent instance is running, regardless of how many times I attach to screen.) See my attach-screen script for specific details.
Splitvt... (none / 3) (#112)GNU stuff tends to be user hostile, but +1 still (none / 2) (#38)
by mikelist on Thu Mar 11, 2004 at 07:20:17 AM EST
is a similar idea, but both/all screens are visible simultaneously. I use that one more, screen is like having several vts logged in at the same time.
Screen as poor guy's VNC (3.00 / 5) (#111)
- Screen can do that, too -nt- by emagius, 03/12/2004 07:20:46 AM EST (3.00 / 2)
by mikeymckay on Thu Mar 11, 2004 at 06:05:17 AM EST
My favorite feature of screen is being able to share a terminal with someone else in real time. It is a great way to collaborate on a project together, or to teach someone how to do various command line magic.The great thing is that the command line is only text, so two users could be on a slow dialup connection, but fully able to work together. It is like sharing a vnc connection, but needing just a fraction of the bandwidth.
To set this up you do something like this:
user1 runs screen
runs command "ctrl-A: multiuser on"
then "ctrl-A: acladd user2"user 2 then runs
screen -x user1(I think the above process may have changed slightly in recent versions due to some security issues)
Mike
www.vdomck.org
making it go away (none / 2) (#118)I agree with you. And their documentation is just as user hostile as their interfaces are.
However, screen is very useful. And its about time someone wrote an article like this because the docs that come with screen try to tell you everything except how to actually get the damn program to be useful.
Just remember 3 commands:
Ctrl-a C to create a new console.
Ctrl-a N and Ctrl-a P to switch between them.Trying to figure out these essential commands using screen's stupid help screen and the docs is close to hopeless.
screen -x (3.00 / 2) (#100)
by Phil Gregory on Thu Mar 11, 2004 at 01:00:09 AM EST
Not sure if this would be of interest to you, but you can attach multiple times to the same screen session. Just usescreen -xinstead ofscreen -r. I work with several xterms visible, but all running screen -x to the same session. That gives me all the benefits of screen combined with the ability to see more things at once.screen displays can themselves be split to show more than one window at once, but they can only be split horizontally and the splits aren't persistent without some hackery. I just run my xterms tiled inside of ion.
355/113 -- Not the famous irrational number PI, but an incredible simulation!Screen makes it less confusing (none / 1) (#78)
by interiot on Wed Mar 10, 2004 at 08:15:14 PM EST
1) you waste screen space by doing that2) that only works with so many windows, after a while you have to start overlapping them. At which point Screen is much less confusing because you just remember things like "screen #1 is my main email box, screen #9 is the mbox for mailing list X, screen #8 is ircii, screen #7 is the build that's taking forever, screen #2 is for the main source file editing, etc....". Changing between numbered terminals is much faster than trying to find the right window to alt-tab to (once you go beyond 3 main windows you're working with).
A real life practical example (3.00 / 9) (#73)
by esrever on Wed Mar 10, 2004 at 07:48:45 PM EST
I need to run an interactive, 36 hour process on a server. The server is headless, so I can only interact with it over a terminal session. I need to be able to take my laptop home with me at night for remote support purposes, so how do I satisfy both the need to detach my laptop, and the need to be able to keep the interactive session running? The answer, of course, is 'screen'. It works beautifully. Why not? (2.75 / 4) (#92)
by John Thompson on Wed Mar 10, 2004 at 10:05:45 PM EST
Phillip Asheo wrote:Why not just run a couple of hundred Xterms and 9wm.
A couple reasons: screen is stateless, meaning you can disconnect from your screen session without disturbing the processes running with screen. In contrast, if you disconnect from an X session, the processes running in that session will die.
Second, if you're connecting through a non-graphical terminal (serial terminal or text console, for example) you can't run X. One of my machines is an old 5x86/133 with 32M running NetBSD. It acts as a DHCP server and samba authentication server for my home network and not much else and it's stable as a rock. The only time I've had to shut it down in the last few months was when I had to replace the UPS. It's possible to run X on that machine, but I'd rather save the limited resources for other things, so I use ssh and screen to access and administer the machine.
X would be pointless in such a case.
An awesome tool (3.00 / 13) (#93)
by Shibboleth on Wed Mar 10, 2004 at 10:24:59 PM EST
'Back in the day', when we used to be on dumb vt100 terminals in any one of a dozen labs at uni, screen was the Best Program Ever.Its ability to switch and detach was beyond useful. For instance, we could be signed in on one server, coding, with one screen in Jove, another in a mail program, and another at a command prompt. We'd then have an ftp session going on a whole different server, and a MUD client or nethack game on yet another screen (on another server).
If some Authority Figure would walk in, a control-a, control-a would be enough to hide our nethack game from view. Best of all, if someone comes in, says 'everybody out, class about to start', you can just do a control-a-d, 'exit', and pick up your bag and leave, go to another lab, and resume precisely where you left off (except for the MUD, you were dead. :))
I still find it useful for my gentoo laptop. I have a root login, start screen, then start compiling some large program. Then I just detach the session, log out, and have a secure laptop sitting there compiling. If someone comes up to it, they can't just alt-function through the terminals and get a nice, open root session on screen.
splitting windows (none / 2) (#27)
by martingale on Tue Mar 09, 2004 at 08:45:18 PM EST
You can also split windows kind of like emacs. That's sometimes more useful than tabbed xterms. Of course, with a big desktop you can just open a couple more xterms and move them around. long-term screen use (3.00 / 9) (#21)
by Baldrson Neutralizer on Tue Mar 09, 2004 at 06:54:15 PM EST
I have used screen for about 10 years, and there was a period where the constant ctrl-a contortions my left hand had to make caused some serious pain in my wrist. I finally clued in a remapped my control key back to the caps lock position (on a standard pc keyboard anyways) like a sun keyboard and the problem diminished greatly.Also, I logged in to a linux machine a while back (I think it might have been red hat, not sure) and I noticed that the screen status bar was appearing in the title bar of my putty session. It was pretty cool. I never spent the time figuring out how to configure that setting on my own machines, but if anybody else knows how, it was a handy feature at the time.
use ctrl-\ instead of ctrl-a, and remap caps lock (none / 2) (#172)
Modern life, in EVERY ASPECT, is a cult of mediocrity.-trhurler
by Shikari on Sun Mar 14, 2004 at 12:57:09 PM EST
I've been a screen user for about 14 years (cs. 1990) and when I started using emacs regularly, I switched my control key from ctrl-a to ctrl-\. I think this works better for the wrists as well as allows be to use ctrl-a normally on the command-line and in emacs. Plus I swap caps lock and right control so that I can use a PC keyboard like a Sun keyboard. Much better for the wrists also.
Another use (2.55 / 9) (#35)
by dn on Wed Mar 10, 2004 at 01:53:05 AM EST
Screen is also nice when, for whatever reason, your terminal keeps getting blown away. You don't have to keep putting all the editors, mail readers, and such back in order from scratch.
screen + bittorrent (3.00 / 5) (#113)
by davros4269 on Thu Mar 11, 2004 at 08:16:40 AM EST
Is a great combination.I use btdownloadcurses and run it in a screen session. At this house, others use this machine, so if they log in, my downloads continue - when I log back in, I open a shell and: screen -r and I can see my progress.
This old crate really feels the bog when I have several downloads going, so I often use an even older crate with lots of ram and no hard drive - it runs Knoppix without X (knoppix 2). I SSH in and use screen so I can watch my downloads in their full ascii glory...
I also keep screen running on my firewall machine, an even older box, also without X running...
Screen is so much nicer than using, say, nohup or similar on a time-intensive command line job. I can't live without it.
How I use it (3.00 / 6) (#115)
Will you squirm when you are pecked? Quack.
by Piquan on Thu Mar 11, 2004 at 08:51:43 AM EST
Two tips from how I use screen.First, if you use Emacs, or the Emacs bindings for bash, then you'll probably want to add escape ^Za to your .screenrc. This lets you use ^Z instead of ^A, so you can use Emacs more naturally. Who needs ^Z in screen anyway, and if you need it, ^Za will do the trick.
Second, I find screen great for multiuser collaboration. I'm helping a friend in his programming studies, usually over the phone. We'll often use a shared screen session, so we can watch each other work on code. The sequence is: he creates a screen session, hits (assuming ^Z is your escape char) ^Z:multiuser on[RET]^Z:acladd piquan[RET] (where my username is piquan); then I run (from a normal, non-screen terminal) screen -x jrh/ (where his username is jrh).
- Better choice for command key: Backquote by Xenophon Fenderson, the Carbon(d)ated, 03/11/2004 09:03:09 AM EST (none / 3)
- I used to use backquote all the time by grouse, 03/11/2004 04:42:27 PM EST (none / 1)
More .screenrc
fun (3.00
/ 7) (#121)
by
fn0rd
on Thu Mar 11, 2004 at 11:03:58 AM EST
#kill startup message
startup_message off
# define a bigger scrollback, default is 100 lines
defscrollback 1024
# on Debian backspace should send char `177':
bindkey -k kb stuff "177"
# An alternative hardstatus to display a bar at
the bottom listing the
# windownames and highlighting the current windowname in blue. (This is
only
# enabled if there is no hardstatus setting for your terminal)
hardstatus on
hardstatus alwayslastline
hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d
%C%a "
# --------------------------------------------------------------------------
# STARTUP SCREENS
# --------------------------------------------------------------------------#
Example of automatically running some programs in windows on screen startup.
# Use the form: screen [-flag] [window name] [window number] [program to
run in window]
# The -t flag means that the window in which that program is running
# closes when you exit that program, so if you quit pine
# window 2 closes.
screen bash
screen -t emacs 1 emacs
screen -t mail 2 pine
screen -t slashdot 3 lynx http://www.slashdot.org/
screen -t k5 4 lynx http://www.kuro5hin.org/
screen -t bar 5 ssh foo@bar
# I cribbed most of this from /etc/screenrc
# Check it out on your own to learn more about keybindings and whatnot.
This fatwa brought to you by the Agnostic Jihad
Yet more screen tricks. (3.00 / 7) (#148)Second: if you find yourself opening more and more screens, you might like the following commands in your .screen.rc.:
bind ) select 10
bind ! select 11
bind @ select 12
bind \# select 13
bind \$ select 14
bind % select 15
bind \^ select 16
bind & select 17
bind * select 18
bind ) select 19
The default commands include Ctrl+a 5 to select screen 5; this makes Ctrl+a Shift+5 select screen 15. :-)
Last; although mention was made of the scrollback (Ctrl+A Esc), you can use this to copy-n-paste between screens. Look in the screens manpage for details but if you use vim you might like this instead of the default:
# Prepend/append register [/] to the paste if ^a^] is pressed.
# This lets me have autoindent modes in vi(m).
register [ "\033:se paste\015a"
register ] "\033:se nopaste\015a"
bind ^] paste [.]
The defaults toggle autoindent mode but that's not always sufficient. And vim's paste mode is actually designed for this.
Wade.
* unlike so much other GNU software, the man page is really quite good and doesn't point you to an info page.
How to map Ctrl-Tab? (none / 1) (#171)Does anybody know how to do this?
Ctrl-Tab would be nicely consistent with many other applications, e.g. switching the active tab in Mozilla. A general standard in Microsoft Windows and many other environments is: Alt-Tab changes the application, Ctrl-Tab changes within an application.
keyboard magic (3.00 / 2) (#175)#aterm bindings
bindkey "^[[c" next
bindkey "^[[d" prev
bindkey "^[Oc" next
bindkey "^[Od" prev
#putty bindings
bindkey "^[OC" next
bindkey "^[OD" prev
#some other term, don't remember which
bindkey "^[[5C" next
bindkey "^[[5D" prev
You should be able to map ctrl-tab in a similar manner.
Oh, and check out this screenrc magic:
termcapinfo xterm "ks=E[?1lE
:kuE[A:kd=E[B:kl=E[D:kr=E[C:kh=E[5~:kH=E[F"(that is three lines in case it wraps - one starting with termcapinfo, second starting with "ks=, third starting with hardstatus.)
Try it out, you'll probably not be able to live without it. It displays a status line at the bottom of the terminal which shows what window you're in and a list of the other windows. You'll probably want to start giving your windows names at that point. Do that via ctrl-a A, and then typing the name.
Trick for transfering files using only terminal. (3.00
/ 5) (#173)
by
Tezcatlipoca
on Sun Mar 14, 2004 at 07:39:35 PM EST
That is right, you have two machines, you only have access to the terminal
servers through serial lines (not uncommon in modern datacenters) and you
need to transfer medium sized files (don't try this with your 100GB MP3
collection).
Using screen define a new buffer file, then use uuencode in the first machine:
uuencode file file
and go to sleep.
Next day (or week :-) ) go to the next machine and try:
cat - <<EOF >> file.uu
at this point type Ctrl-a ] which pastes screen's buffer, once finished type EOF and CTRL-D
now you can
uudecode file.uu
and you get your file in all its glory.
This trick saved me one week of internal bureaucracy....
Might is right
Freedom? Which freedom?
Run bitchX or irc2 under a screen session on a stable server that you
can ssh to. Then detach and reattach whenever you need to.
Detaching sessions (none
/ 0) (#191)
Updated 13 Sep 04. Nevermind. phil_g's comment says it well. keychain is the way to go. I'll rewrite this when I have more time.Some co-workers turned me on to GNU screen last year. It's a handy addition to my toolbox. It became most useful after I learned how to use it with SSH. The original URL that gave me the solution appears to be gone (a message in the now-defunct gnu-screen Yahoo group). So I thought I'd write this up and see how it fares when people google gnu screen ssh.
The solution I settled on is a nested invocation I learned from Jason White. I recommend you read my screenrc and my slave screenrc in another window and read along here for commentary. You run an "outer" screen session (the "slave" session) that in turn runs an "inner" (or "master") session. You use the regular escape sequence (Ctrl-A d) to detatch from the master, and you map Ctrl-^ to be the control key for the slave session. If you press Ctrl-^ while using screen this way, you'll see one process in the slave session. It's running ssh-agent. That's the key to using ssh with screen. The slave's only purpose is to run ssh-agent. The master runs as a child of that. Consequently, all shells in the master session are running under the ssh-agent. Just run ssh-add from any master shell, and then all shells have your ssh identity.
For more information about GNU screen, see GNU Screen: an introduction and beginner's tutorial or Power Sessions with Screen. For more information about SSH, see openssh.com.
Nested Screens Not Necessary
phil_g
2004-07-06 08:57 am UTC (link)You don't need to use nested screens to get this effect. I achieve it by the use of a simple wrapper script for screen. To attach to a screen session, I have a single script that I run; it loads the agent before starting screen. (I use keychain to ensure that only one agent instance is running, regardless of how many times I attach to screen.) See my attach-screen script for specific details. [Feb 12, 2004] Curiosity is bliss Essential utility screen
Screen is a command line utility that comes with lots of Unix variants (including Linux). It is a bit hard to describe and to discover. It provides two main features: multiplexing a terminal and detaching/re-attaching sessions.
I originally got shown this by my "System programming" TA, when I asked him if I could disconnect X11 application from one terminal and have them re-open (in the same state) onto another terminal. It turns out this is possible for X11 applications (see xmove or xmx, proxy-based redirections, or guiEvict <via sweetcode>, described in this paper). But "screen" although limited to text applications is so useful that I dropped my search for its X11 equivalent.
Multiplexing: If you start a remote shell (say SSH) but want to do more than one thing at a time, you may want to open more sessions, but you can also use screen. It allows you to switch between multiple shells on the same connection.
You need to first run "screen", then use "Ctrl-A Ctrl-C" (control A, control C) to create a new shell, and you now can switch between shells with "Ctrl-A Ctrl-*" where * is the number for you shell (for ex, use "Ctrl-A Ctrl-1" to switch to shell 1).Session migration: Let's say you need to disconnect from that session, but you want to continue it from another computer. You can use "Ctrl-A Ctrl-D" to detach screen. All the shells will be maintained, and you can reconnect to the remote machine again and type "screen -R" to re-attach to the original session. This is also very useful in can the connection is lost by accident.
macosxhints.com - Use 'screen' as a serial terminal emulator
I often have to do router configuration via a console port, so I use a Keyspan Serial Adapter to get access. Two problems then present themselves:Solution: Use screen, Terminal, and a little AppleScripting.
- ZTerm is a horrible Mac OS X app. It hasn't been updated in five years or so, and isn't a Universal Binary. The developer doesn't seem in any hurry to rectify the situation. It is not worth the shareware fee in its current form.
- Minicom requires installation of Fink or MacPorts and is overly complex.
First, launch Script Editor and type/paste in the following code:Compile and save as an app from within Script Editor, and you have a double-clickable application to launch a serial Terminal session. You may want to customize this slightly -- you can change the screen colors or number of columns or rows. You may also need to customize the screen command with a different device name if you are using something other than the Keyspan Serial Adapter (do an ls tty* of the /dev/ directory to get the right name).tell application "Terminal" do script with command "screen /dev/tty.KeySerial1" set number of rows of window 1 to 100 set number of columns of window 1 to 80 set background color of window 1 to "black" set normal text color of window 1 to "green" set custom title of window 1 to "SerialOut" end tell
screen uses Control-A to take commands directed to it. So type Control-A followed by Control-\ to exit your screen session. If you fail to do this and exit a Terminal session, you'll leave the screen session alive and the serial resource unavailable until you kill the screen session manually. man screen will show you further commands to send to a screen session.
If anyone can reply with a link to a tutorial on how to wrap an interactive Unix App in Cocoa, that would be the next step -- it would be nice to do this without involving Terminal. If you prefer to use Minicom, you could still use the AppleScript to wrap it into a nice launchable app -- use this older hint to find the right command line commands.
Solaris Packages
Solaris Package Archive -- GNU screen 3.9.4
GNU screen 3.9.4 provides you with an ANSI/vt100 terminal emulator, which can multiplex up to 10 pseudo-terminals. On startup, it executes $SHELL in window 0. Then it reads $HOME/.screenrc to learn configuration, keybindings, and possibly open more windows. GNU screen has the ability to detach from your virtual screens and re-attach at a later time.
Email To
Send bug reports or queries to screen@uni-erlangen.de.
Upgrading Packages
When upgrading from an earlier GNU screen package, remember to pkgrm GNUscreen before you pkgadd the new version.
Solaris Issues
Click here to read about 32 bit and 64 bit packages.
Source Code
You can ftp the source code from ftp://ftp.gnu.org/pub/gnu/screen/screen-3.9.4.tar.gz
Special Issues
You may need to configure your terminal definitiosn to get the most out of GNU screen. See the files in the /usr/local/share/screen directory for more information.
See the main packages README for installation information.
Screen User's Manual - Table of Contents
I love to keep an eye on #gentoo using my favourite IRC client irssi and read emails/Usenet posts/do whatever without clobbering my monitor.Similar to vim, which not all of us reportedly prefer, we can use a single terminal window for more than one visible task.
Screen can horizontally split into regions, each holding a different terminal. To open a new region one types Ctrl-a S (capital s, please!). To enter that newly created region we have to tab into it: Ctrl-a <Tab> Still nothing can be seen, but we can now cycle through our open terminals with Ctrl-a n or Ctrl-a p. To close a region type Ctrl-a X.
A region with focus can be resized with Ctrl-a + or Ctrl-a - By default this changes the height by 3 lines. Alternatively, you can specify the height to an absolute number by going into Screens command mode. Ctrl-a X removes the current region.
Each window in a screen session emulates a VT100 terminal, with some extra functions added. The VT100 emulator is hardcoded; no other terminal types can be emulated.
Usually screen tries to emulate as much of the VT100/ANSI standard as possible. But if your terminal lacks certain capabilities, the emulation may not be complete. In these cases screen has to tell the applications that some of the features are missing. This is no problem on machines using termcap, because screen can use the $TERMCAP variable to customize the standard screen termcap.
But if you do a rlogin on another machine or your machine supports only terminfo this method fails. Because of this, screen offers a way to deal with these cases. Here is how it works:
When screen tries to figure out a terminal name for itself, it first looks for an entry named “screen.<term>”, where <term> is the contents of your $TERM variable. If no such entry exists, screen tries “screen” (or “screen-w” if the terminal is wide (132 cols or more)). If even this entry cannot be found, “vt100” is used as a substitute.
The idea is that if you have a terminal which doesn’t support an important feature (e.g. delete char or clear to EOS) you can build a new termcap/terminfo entry for screen (named “screen.<dumbterm>”) in which this capability has been disabled. If this entry is installed on your machines you are able to do a rlogin and still keep the correct termcap/terminfo entry. The terminal name is put in the $TERM variable of all new windows. Screen also sets the $TERMCAP variable reflecting the capabilities of the virtual terminal emulated. Notice that, however, on machines using the terminfo database this variable has no effect. Furthermore, the variable $WINDOW is set to the window number of each window.
The actual set of capabilities supported by the virtual
terminal depends on the capabilities supported
by the physical terminal. If, for instance,
the physical terminal does not support underscore
mode, screen does not put the us
and ue capabilities into the window’s $TERMCAP variable, accordingly.
However, a minimum number of capabilities must be supported by a
terminal in order to run
screen; namely scrolling, clear
screen, and direct cursor addressing (in
addition, screen does not run on hardcopy
terminals or on
terminals that overstrike).
Also, you can customize the $TERMCAP value used by screen by using the “termcap” .screenrc command, or by defining the variable $SCREENCAP prior to startup. When the is latter defined, its value will be copied verbatim into each window’s $TERMCAP variable. This can either be the full terminal definition, or a filename where the terminal “screen” (and/or “screen-w”) is defined.
Note that screen honors the “terminfo” .screenrc command if the system uses the terminfo database rather than termcap.
When the boolean ‘G0’ capability is present in the termcap entry for
the terminal on which
screen has been called, the
terminal emulation of
screen supports multiple character sets.
This allows an application to make use of, for instance, the VT100 graphics
character set or national character sets. The following control functions
from ISO
2022 are supported: lock shift G0 (SI), lock shift G1 (SO),
lock shift G2, lock shift G3, single shift G2, and single shift G3. When
a virtual terminal is created or reset,
the
ASCII character set is designated as G0 through G3. When the
G0 capability is present, screen
evaluates the capabilities S0, E0, and C0
if present. S0 is the sequence the
terminal uses to enable and start the graphics character set rather
than SI. E0 is the corresponding replacement for
SO. C0 gives a character by character translation
string that is used during semi-graphics mode. This string is built like
the acsc terminfo capability.
When the po and pf capabilities are present
in the terminal’s termcap entry, applications
running in a screen window can send output
to the printer port of the terminal. This
allows a user to have an application in one window sending output to a printer
connected to the terminal, while all other
windows are still active (the printer port is enabled and disabled again
for each chunk of output). As a side-effect, programs running in different
windows can send output to the printer simultaneously. Data sent to the
printer is not displayed in the window. The info command displays a line
starting ‘PRIN’ while the printer is active.
Screen maintains a hardstatus line for
every window. If a window gets selected, the display’s hardstatus will be
updated to match the window’s hardstatus line. If the display has no hardstatus
the line will be displayed as a standard screen
message. The hardstatus line can be changed with the ANSI Application Program
Command (APC): ESC_<string>ESC\. As a convenience
for xterm users the sequence ESC]0..2;<string>^G is
also accepted.
Some capabilities are only put into the $TERMCAP variable of the virtual
terminal if they can be efficiently implemented
by the physical terminal. For instance,
dl (delete line) is only put into the $TERMCAP variable if
the terminal supports either delete line
itself or scrolling regions. Note that this may provoke confusion, when
the session is reattached on a different terminal,
as the value of $TERMCAP cannot be modified by parent processes.
The “alternate screen” capability is
not enabled by default. Set the altscreen
.screenrc command to enable it.
The following is a list of control sequences recognized by screen. “(V)” and “(A)” indicate VT100-specific and ANSI- or ISO-specific functions, respectively.
ESC E |
Next Line | |||
ESC D |
Index | |||
ESC M |
Reverse Index | |||
ESC H |
Horizontal Tab Set | |||
ESC Z |
Send VT100 Identification String | |||
ESC 7 |
(V) | Save Cursor and Attributes | ||
ESC 8 |
(V) | Restore Cursor and Attributes | ||
ESC [s |
(A) | Save Cursor and Attributes | ||
ESC [u |
(A) | Restore Cursor and Attributes | ||
ESC c |
Reset to Initial State | |||
ESC g |
Visual Bell | |||
ESC Pn p
|
Cursor Visibility (97801) | |||
Pn = |
6 | Invisible | ||
| 7 | Visible | |||
ESC = |
(V) | Application Keypad Mode | ||
ESC > |
(V) | Numeric Keypad Mode | ||
ESC # 8 |
(V) | Fill Screen with Es | ||
ESC \ |
(A) | String Terminator | ||
ESC ^ |
(A) | Privacy Message String (Message Line) | ||
ESC ! |
Global Message String (Message Line) | |||
ESC k |
A.k.a. Definition String | |||
ESC P |
(A) | Device Control String. Outputs a string directly to the host terminal without interpretation. | ||
ESC _ |
(A) | Application Program Command (Hardstatus) | ||
ESC ] 0 ; string
^G |
(A) | Operating System Command (Hardstatus, xterm title hack) | ||
ESC ] 83 ; cmd
^G |
(A) | Execute screen command. This
only works if multi-user support is compiled into
screen. The pseudo-user “:window:”
is used to check the access control list. Use aclchg :window:
-rwx #? to create a user with no rights and allow only the
needed commands. |
||
Control-N |
(A) | Lock Shift G1(SO) | ||
Control-O |
(A) | Lock Shift G0 (SI) | ||
ESC n |
(A) | Lock Shift G2 | ||
ESC o |
(A) | Lock Shift G3 | ||
ESC N |
(A) | Single Shift G2 | ||
ESC O |
(A) | Single Shift G3 | ||
ESC ( Pcs
|
(A) | Designate character set as G0 | ||
ESC ) Pcs
|
(A) | Designate character set as G1 | ||
ESC * Pcs
|
(A) | Designate character set as G2 | ||
ESC + Pcs
|
(A) | Designate character set as G3 | ||
ESC [ Pn ;
Pn H |
Direct Cursor Addressing | |||
ESC [ Pn ;
Pn f |
same as above | |||
ESC [ Pn J
|
Erase in Display | |||
Pn = |
None or 0 | From Cursor to End of Screen | ||
| 1 | From Beginning of Screen to Cursor | |||
| 2 | Entire Screen | |||
ESC [ Pn K
|
Erase in Line | |||
Pn = |
None or 0 | From Cursor to End of Line | ||
| 1 | From Beginning of Line to Cursor | |||
| 2 | Entire Line | |||
ESC [ Pn X
|
Erase character | |||
ESC [ Pn A
|
Cursor Up | |||
ESC [ Pn B
|
Cursor Down | |||
ESC [ Pn C
|
Cursor Right | |||
ESC [ Pn D
|
Cursor Left | |||
ESC [ Pn E
|
Cursor next line | |||
ESC [ Pn F
|
Cursor previous line | |||
ESC [ Pn G
|
Cursor horizontal position | |||
ESC [ Pn '
|
same as above | |||
ESC [ Pn d
|
Cursor vertical position | |||
ESC [ Ps ;...;
Ps m |
Select Graphic Rendition | |||
Ps = |
None or 0 | Default Rendition | ||
| 1 | Bold | |||
| 2 | (A) | Faint | ||
| 3 | (A) | Standout Mode (ANSI: Italicized) | ||
| 4 | Underlined | |||
| 5 | Blinking | |||
| 7 | Negative Image | |||
| 22 | (A) | Normal Intensity | ||
| 23 | (A) | Standout Mode off (ANSI: Italicized off) | ||
| 24 | (A) | Not Underlined | ||
| 25 | (A) | Not Blinking | ||
| 27 | (A) | Positive Image | ||
| 30 | (A) | Foreground Black | ||
| 31 | (A) | Foreground Red | ||
| 32 | (A) | Foreground Green | ||
| 33 | (A) | Foreground Yellow | ||
| 34 | (A) | Foreground Blue | ||
| 35 | (A) | Foreground Magenta | ||
| 36 | (A) | Foreground Cyan | ||
| 37 | (A) | Foreground White | ||
| 39 | (A) | Foreground Default | ||
| 40 | (A) | Background Black | ||
| ... | ||||
| 49 | (A) | Background Default | ||
ESC [ Pn g
|
Tab Clear | |||
Pn = |
None or 0 | Clear Tab at Current Position | ||
| 3 | Clear All Tabs | |||
ESC [ Pn ;
Pn r |
(V) | Set Scrolling Region | ||
ESC [ Pn I
|
(A) | Horizontal Tab | ||
ESC [ Pn Z
|
(A) | Backward Tab | ||
ESC [ Pn L
|
(A) | Insert Line | ||
ESC [ Pn M
|
(A) | Delete Line | ||
ESC [ Pn @
|
(A) | Insert Character | ||
ESC [ Pn P
|
(A) | Delete Character | ||
ESC [ Pn S
|
Scroll Scrolling Region Up | |||
ESC [ Pn T
|
Scroll Scrolling Region Down | |||
ESC [ Pn ^
|
same as above | |||
ESC [ Ps ;...;
Ps h |
Set Mode | |||
ESC [ Ps ;...;
Ps l |
Reset Mode | |||
Ps = |
4 | (A) | Insert Mode | |
| 20 | (A) | Automatic Linefeed Mode | ||
| 34 | Normal Cursor Visibility | |||
| ?1 | (V) | Application Cursor Keys | ||
| ?3 | (V) | Change Terminal Width to 132 columns | ||
| ?5 | (V) | Reverse Video | ||
| ?6 | (V) | Origin Mode | ||
| ?7 | (V) | Wrap Mode | ||
| ?9 | X10 mouse tracking | |||
| ?25 | (V) | Visible Cursor | ||
| ?47 | Alternate Screen (old xterm code) | |||
| ?1000 | (V) | VT200 mouse tracking | ||
| ?1047 | Alternate Screen (new xterm code) | |||
| ?1049 | Alternate Screen (new xterm code) | |||
ESC [ 5 i |
(A) | Start relay to printer (ANSI Media Copy) | ||
ESC [ 4 i |
(A) | Stop relay to printer (ANSI Media Copy) | ||
ESC [ 8 ; Ph ;
Pw t |
Resize the window to Ph lines and Pw columns (SunView special) | |||
ESC [ c |
Send VT100 Identification String | |||
ESC [ x |
Send Terminal Parameter Report | |||
ESC [ > c |
Send VT220 Secondary Device Attributes String | |||
ESC [ 6 n |
Send Cursor Position Report | |||
Screen has the following command-line options:
dtach is a tiny program that emulates the detach feature of screen, allowing you to run a program in an environment that is protected from the controlling terminal and attach to it later. dtach does not keep track of the contents of the screen, and thus works best with programs that know how to redraw themselves.dtach does not, however, have the other features of screen, such as its support of multiple terminals or its terminal emulation support. This makes dtach extremely tiny compared to screen, making it more easily audited for bugs and security holes, and also allows it to fit in environments where space is limited, such as on rescue disks.
dtach has many possible uses, even though it is tiny. With dtach, you can:
- Attach multiple times to the same program. Access to the dtach session is controlled through the Unix filesystem permissions; thus, you can trivially allow other people to watch your session.
- Run a program in an environment that is protected from the controlling terminal. This means that, for instance, the program running under dtach would not be affected by the terminal being disconnected for some reason.
- Run programs such as emacs, which tend to want full control over the terminal. dtach mostly acts as a relay, and does not mangle the text between the application and your terminal.
- Suspend dtach without suspending the running program. dtach can handle the suspend key itself instead of passing it to the running program, which may be useful for certain programs such as ircII.
The latest version of dtach is version 0.7, which you can fetch here. Other download formats may be available at the sourceforge download area for dtach.The changes in version 0.7 are:
The changes in version 0.6 are:
- The redraw method can now be explicitly specified on the command line (either no redraw at all, the old ^L character method, and the new WINCH signal method), since many programs only handle one or the other properly.
- Changed the default redraw method back to the old ^L character method.
- Changed the attach code to check the return value of select more carefully.
- Changed the SIGWINCH handler to reinstall itself, to handle systems that always reset the handler.
- Added more proper process group handling.
The changes in version 0.5 are:
- Redraws are now handled by sending the child process a WINCH signal instead of by sending a ^L character. This should help prevent line-oriented programs (such as bash) from clearing the screen excessively.
- Flow control is now disabled when setting raw mode on the terminal.
- Switched to using select instead of poll.
- Changed some exits to exit succesfully instead of non-sucessfully.
- Updated my email address.
- Updated to Autoconf 2.59, renaming some files in the process.
The changes in version 0.4 are:
- Fix fd leakage.
- Prevent atexit from being called twice on dtach -A.
The changes in version 0.3 are:
- Slightly improved README and dtach.1
- Portability updates thanks to sourceforge's compile farm. dtach should now work on: FreeBSD, Debian/alpha, Debian/sparc, Debian/PPC, and Solaris.
You can also obtain information on how to access the CVS tree here, and access the sourceforge project page here.
- Fixed a typo in dtach.1
- Changed the attach code so that it tells the master when a suspend occurs.
- Decreased the client <-> master packet size.
- Changed the master to send a stream of text to attaching clients instead of sending a huge packet all the time.
- Use getrlimit and dynamically allocate the data structures, if possible.
- Added some more autoconf checks.
- Initial sourceforge release.
You can send any comments or questions about dtach to the author. Comments and suggestions are welcome.
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer:
Last modified: June 19, 2009
I have even found it useful for when I'm staying next to the screen (not just going away to dinner or something). Depending on where I am, sometimes my ssh connection will drop due to bad wireless (or other) connections or due to ssh timeouts while I wait. If I was using screen, I didn't have to dettach the screen...if the connection was lost, the screen is available to reattach when I log back in.