Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Screen Bulletin, 2001-2010

Prev | Contents | Next
Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Oct 19, 2010] Screen - s5h.net

[Oct 19, 2010] Make GNU Screen Your Default Shell

George's tip actually makes a lot of sense ! In Linux you can put in cron an automatic restart of screen in case of reboot using @reboot.
October 18 2010 | ServerWatch.com

Celsius1414:

Or better yet, especially if you're on a multi-user system, edit ~/.screenrc instead.

george >: -[This is an interesting idea --NNB]

If I understand your write-up then you'll have a ton of screen sessions on your system because everytime you log in you'll create another screen.

Instead, I first login and create a screen session called main using screen -S main

I have the end of my .bash_profile set to run screen -D -R main. That way whenever I log in it'll automatically Disconnect then Reconnect my screen session - bingo bango bongo - only one screen session running at a time.

As a funny bonus I now know everytime the server's rebooted because my main screen session goes away and I have to restart it.

By archtaku :

I do something similar on my laptop and netbook. There's an environment variable that is set in a shell which was started inside a GNU Screen session, which is called STY. By checking if the value of $STY is zero-length, one can easily tell whether or not you are already within a screen session, and launch screen if you're not:

[ -z "$STY" ] && screen

On my office workstation I also launch screen this way, but since I often login to it remotely (unlike my laptop) I also check to see if SSH_CONNECTION is zero-length:

[ -z "$STY" ] && [ -z "$SSH_CONNECTION" ] && screen

This means I still need to launch screen manually when logging in remotely, but I often leave a screen session running on my workstation (because I'm in the middle of something) and resume it once I login.

Edo:

Maybe I'm a bit "old fashion" but I like screenie http://goo.gl/xVj4

Screenie is a small and lightweight GNU screen(1) wrapper that is designed to be a session handler that simplifies the process of administrating detached jobs by providing an interactive menu.

Reply to this commentBy pbrisbin October 19 2010 8:39 PMPDT Nice post.

I actually use a combination of environment variables and bash aliases to make `irssi` launch or reconnect an in-screen instance of irssi; similarly, `rtorrent` launches or reconnects an in-screen instance of rtorrent.

I also have a main screen session that opens when I just type `screen`, maybe I'll start launching/reconnecting that one at login through .bashrc like you suggest.

If you're interested, in my method: http://pbrisbin.com/posts/screen_tricks/

[Oct 19, 2010] Taking Command of the Terminal with GNU Screen by Joe 'Zonker' Brockmeier

February 11, 2010 | linux.com

Attaching and Detaching from Screen

One of the most powerful features of screen is the ability to detach and attach to running sessions. If you tend to work from several machines, it might be a good habit to start an instance of screen when you log in. Then if you're at a different system you can simply attach or re-attach to the running session and resume where you left off.

Note that you can also share a screen session, so it's not necessary to detach from a session in order to log into the same session from another location. So, for example, if you've logged into a system remotely using SSH and then started a screen session, you could then go to another computer and attach to the same session.

To see which sessions are running, use screen -ls. This will display all running sessions, and the process IDs (PIDs). If you have more than one session running, you will need to know the PID to attach or reattach to an existing session. To detach a session, use Ctrl-a d. If that's the only session running, you can reattach with Ctrl-a r If more than one session is detached, you'll need to run Ctrl-a r XXXXX where XXXXX is the PID.

To connect to a session that's still attached, use Ctrl-a x XXXXX instead. This will let you re-attach to an existing session without any problems.

Can I have a Copy of That?

Want a quick and dirty way to take notes of what's on your screen? Yep, there's a command for that. Run Ctrl-a h and screen will save a text file called "hardcopy.n" in your current directory that has all of the existing text. Want to get a quick snapshot of the top output on a system? Just run Ctrl-a h and there you go.

You can also save a log of what's going on in a window by using Ctrl-a H. This will create a file called screenlog.0 in the current directory. Note that it may have limited usefulness if you're doing something like editing a file in Vim, and the output can look pretty odd if you're doing much more than entering a few simple commands. To close a screenlog, use Ctrl-a H again.

Note if you want a quick glance at the system info, including hostname, system load, and system time, you can get that with Ctrl-a t.

Simplifying Screen with Byobu

If the screen commands seem a bit too arcane to memorize, don't worry. You can tap the power of GNU Screen in a slightly more user-friendly package called byobu. Basically, byobu is a souped-up screen profile originally developed for Ubuntu. Not using Ubuntu? No problem, you can find RPMs or a tarball with the profiles to install on other Linux distros or Unix systems that don't feature a native package.

Note that byobu doesn't actually do anything to screen itself. It's an elaborate (and pretty groovy) screen configuration customization. You could do something similar on your own by hacking your ~/.screenrc, but the byobu maintainers have already done it for you.

Since most of byobu is self-explanatory, I won't go into great detail about using it. You can launch byobu by running byobu. You'll see a shell prompt plus a few lines at the bottom of the screen with additional information about your system, such as the system CPUs, uptime, and system time. To get a quick help menu, hit F9 and then use the Help entry. Most of the commands you would use most frequently are assigned F keys as well. Creating a new window is F2, cycling between windows is F3 and F4, and detaching from a session is F6. To re-title a window use F8, and if you want to lock the screen use F12.

The only downside to byobu is that it's not going to be on all systems, and in a pinch it may help to know your way around plain-vanilla screen rather than byobu.

For an easy reference, here's a list of the most common screen commands that you'll want to know. This isn't exhaustive, but it should be enough for most users to get started using screen happily for most use cases.

Finally, if you want help on GNU Screen, use the man page (man screen) and its built-in help with Ctrl-a :help. Screen has quite a few advanced options that are beyond an introductory tutorial, so be sure to check out the man page when you have the basics down.

[Aug 06, 2010] Re Vertical split in GNU screen

Aug 06, 2010 | Cygwin list

[email protected]

On Fri, Aug 06, 2010 at 03:50:28PM +0200, flo wrote:
Hi, i'm new with mailing-lists use! i'd like to re-talk about a feature with cygwin screen! How can we add the marvellous "Vertical split in GNU screen" with cygwin? I know there were a talk about that between Jeenu V <jeenuv at gmail dot com> and Andrew Schulman <schulman dot andrew at epamail dot epa dot gov> the 19 Apr 2010! Thanks in advance for somebody answer! If i'm not at the right place to talk about this or if i don't use this list in the good way, please don't shout at me, just show me!

Florent LOTTIN

Andrew Schulman-3

this post by [email protected]

> Hi, i'm new with mailing-lists use!
> i'd like to re-talk about a feature with cygwin screen! How can we add the marvellous "Vertical split in GNU screen" with cygwin?

> I know there were a talk about that between Jeenu V <jeenuv at gmail dot com> and Andrew Schulman <schulman dot andrew at epamail dot epa
> dot gov> the 19 Apr 2010! Thanks in advance for somebody answer!

> If i'm not at the right place to talk about this or if i don't use > this list in the good way, please don't shout at me, just show me!

> Florent LOTTIN

...[show rest of quote]


Hi Florent. There is a patch that's been available for a while, that adds vertical split support to screen. I believe that Debian, Ubuntu, and probably others already incorporate it into their official screen packages.

I remember the exchange with Jeenu, and after that I did go get the patch, build screen with it for Cygwin, and try it out. What I found, if I remember right, is that I saw a lot of what I considered strange behavior, and very little documentation or help about how the vertical split feature is supposed to work. It didn't seem to me to be working very well, so I put it aside.

If people would like to try out the patched version, I can post it as a test release. Maybe you can tell me if the vertical split feature is working the way it's supposed to.

Andrew.


--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

[email protected]
Thanks a lot for your quick answer! I will be pleased if you could post the version of Screen with vsplit patch as a test release because i didn't try to compile for cygwin yet! I will try it and give my feedback! I'm on winxp sp3!

Rgds,
Florent..

[Jun 27, 2010] Screen - s5h.net

Automation

It took a while but I thought there would be a way to send some data to a pts to prevent it from timing a session out, although this path proved too complex through /dev/pts and unfruitful for me. GNU Screen does have a mechanism to do this however, though -X. For example, from cron, I've configured this, to send the .info command to a screen session: 

1       1       *       *       *       /usr/local/bin.sun4/screen -rd talker -X stuff '^U.info^M'

This, tells the session named 'talker' to stuff the text '.info' into the session. Replace ^U and ^M with ctrl-v followed by u/m (carriage return character), this simulates the user clearing the line and typing .info followed by the return key.

Automation can be further enhanced though the -p argument.

Screen makes it very handy if you want to automate both the left and right hand site of an application (simulate the user and server).

scroll back

Scroll back isn't as friendly as in vim, but there is some overlap with the key strokes

keystroke action
h Move the cursor left by one character
j Move the cursor down by one line
k Move the cursor up by one line
l Move the cursor right by one character
0/^ Move to the beginning of the current line
$ Move to the end of the current line
g Move to the begging of the buffer
G Moves to the specified line (defaults to the end of the buffer)
C-u Scrolls a half page up
C-b Scrolls a full page up
C-d Scrolls a half page down
C-f Scrolls the full page down

marking

keystroke purpose
v Sets line numbers
a/A Press this after selecting text and the following space will

append marked text to the buffer rather than overwriting the contents, uppercase to toggle

> This writes the buffer to the screen-exchange file where the

contents can be read later.

x reposition the start of the marker

sessions

Suppose you want a set of sessions created to various hosts, one way to do that might be something along the lines of: 

$ screen -d -m -S mega
$ for i in host1 host2 host3 ; do screen -rd mega -X screen -t $i ssh $i ; done;

This will create three sessions to host[1..3] with the title of host[1..3].

This is perhaps one of the most useful features that I've found with screen (besides all the other useful things of course). There is a maximum of 40 windows allowed with the default build of screen. If you want to change this, reconfigure your screen build with -DMAXWIN=255, or edit the config and set the MAXWIN there.

When using the screen command it might be worth noting the following very useful parameters

parameter description
-T Sets the TERM environment, such as vt100, xterm, xterm-color and xterm-256color. This is highly useful if the default TERM does not support the bells and whistles of xterm
-M Monitors the window for activity
-t Sets the title of the window

pre-selection

In the previous example we have a number of screen windows with title host1. Should you wish to select for example host1 and list a file, then write something to the terminal you might do something like this: 

$ screen -rd mega -p host1 -X stuff 'ls -al ~/.screenrc^Mecho joy^M'

I hope this gives you an idea of how even more useful screen can be than it first appears!

I often use pre-selection when the window list cannot be searched through, for example rather than scan through 40 window titles with my eye balls I can drop out of the screen session and use screen -r -p name to jump to the window title name.

[Jun 27, 2010] switching from gnu screen to tmux (updated)

Linux~ized

update #1: upstream accepted my patch, so the next tmux release will provide window-status-alert-{attr,fg,bg} Only difference is the use of alert instead of flagged. It sounds better anyway I'll adjust my patch on 1.2 as well

update #2 [2010/05/17]: uploaded my updated config file, now using ` as my prefix key

I gave tmux a try yesterday.

Clean config file, thorough documentation and a few nice touches here and there (i.e. better, persistent window splitting) make it a nice alternative to screen, but the biggest difference lies in memory usage. Screen can easily eat up to 40-50mb with just a few windows open, but tmux has yet to reach the 10mb mark!

You may argue that ram is cheap these days, but when you're on a 360mb VPS ram matters

I did find a few bugs/annoyances, for instance if you add set-option -g default-terminal "screen-256color" in your config file, tmux stops evaluating the #T variable.

I hacked my way out of this one by adding the following in my .bash_profile instead:

[[ $TERM == "screen" ]] && export -p TERM="screen-256color"

Turns out that's not tmux's fault but bash's, I'll have to create a patch for that as well If you have the same issue, you can use the above hack as a temporary fix.

Also version 1.2 does not provide a way for you to customize the colors used on window titles with alerts (either monitored or when the bell is active), but I patched that and sent it upstream

You can find an ebuild with the patch in my overlay, wirelay (layman -a wirelay ).

The patch was accepted upstream so it'll be in the next release.

# ` is an interesting key for a prefix
set-option -g prefix `
# set-option -g prefix C-a

unbind-key C-b
bind-key C-a last-window
bind-key ` last-window
bind-key a send-prefix

# we might need ` at some point, allow switching
# we can also send the prefix char with `-a
bind-key F11 set-option -g prefix C-a
bind-key F12 set-option -g prefix `

# 0 is too far from `
set -g base-index 1

# set-option -g default-terminal "screen-256color"
set-option -g mouse-select-pane on
set-option -g status-keys vi
set-option -g bell-action any
set-option -g set-titles on
set-option -g set-titles-string '#H:#S.#I.#P #W #T' # window number,program name,active (or not)
set-option -g visual-bell on

setw -g mode-keys vi
setw -g mode-mouse on
setw -g monitor-activity on

bind e previous-window
bind f next-window
bind j up-pane
bind k down-pane

set-option -g status-utf8 on
# set-option -g status-justify centre
set-option -g status-justify left
set-option -g status-bg black
set-option -g status-fg white
set-option -g status-left-length 40

set-option -g pane-active-border-fg green
set-option -g pane-active-border-bg black
set-option -g pane-border-fg white
set-option -g pane-border-bg black

set-option -g message-fg black
set-option -g message-bg green

#setw -g mode-bg black

setw -g window-status-bg black
setw -g window-status-current-fg green
setw -g window-status-alert-attr default
setw -g window-status-alert-fg yellow

set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'

# set -g status-right '#[fg=green]][#[fg=white] #T #[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'
set -g status-right '#[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

set -g history-limit 4096

# `+r reloads the configuration, handy
bind r source-file ~/.tmux.conf

Selected Comments

Dan Douglas:

I gave tmux a serious effort a few months ago. There's a few things that made me switch back to screen.

1) Tmux doesn't support mouse dragging. If you use Vim in Screen you can "set ttymouse=xterm2″ in .vimrc and you can drag visual selections and have them show up in your X copy buffer, and it defines a protected region for the area you actually want to select. You can even drag to resize vim's split windows. None of that works in Tmux. If you do vertical splitting, tmux it selects text from both sides of the split, and with line numbering on it selects the numbers unless you :set nonumber. Yes, just like screen Tmux has it's own copy/paste system – but it's slow to use. You end up with 3 different buffers for X, Screen, and your editor and it becomes a pain especially when working from putty.

2) Tmux handles windows very differently from screen. What Vim calls "tabs", tmux calls "windows", what Vim and screen call "windows", tmux calls "panes", and what Vim and Screen call "buffers", tmux has no equivalent – which is has been a huge pain in the ass until possibly the latest version of Tmux which added the join-pane command which I haven't tried since it was released. Still, I find working with it in that way a bit unnatural.

Clearly Tmux looks like the better long-term solution. It's configuration actually makes sense and it's session handling are superior to screen.

Screen development is stalled and the live ebuild from the berkano overlay with the vertical split patch hasn't been building for the last 6 months or so. Since switching to xmonad as a tiling wm really the only thing I need is the detachable sessions support, which Screen does just fine.

wired :

You probably had mouse-select-pane set to on. That way, tmux grabs the mouse click. You can still hold down the shift key to mark things by clicking and dragging Not sure if you can make tmux define a protected region though.

Join-pane and break-pane work as advertised in 1.2.

I don't use splitting much on localhost either, since I'm using the awesome window manager, but splitting is very useful when doing work over ssh

Dan Douglas:

Yeah splitting is definitely useful over ssh. That's primarily why I started using it.

I tried turning mouse-select-pane off. I had a chat with one of the tmux devs on irc a few months ago and apparently the problem is simply that they don't implement that yet. My workaround was setting a hotkey in vim to turn line numbers on and off so it's possible to copy/paste between a browser window without having to abuse xclip too much.

I didn't realize Screen was that hard on resources either. Kinda stinks. I've been using Konsole too which apparently isn't so lightweight. I like it though since I have kde installed anyway and has always worked flawlessly.

krigstask:

I've switched to tmux recently too, but I'm not that advanced user, so the only thing bothering me is that I can't figure out how to do something similar to `screen -RD`. If remote box has been rebooted, I don't want to run `tmux attach`, then see it failing, run `tmux` and then reattach to it again. I think it could be somehow worked around, but didn't succed myself.

wired:

you could define an alias (or write a small bash script) that does that automatically:

alias mytmux="tmux a -d || tmux"

Alex:

The biggest memory saving I made on my machine recently was switching away from gnome-terminal to urxvt(d). I've never really noticed much of a memory issue with screen although I do wish it was easier to script/configure. I shall check out tmux when I next have a spare few hours

sylware :

gnu screen and tmux are bloatware.

I swtiched to dtach. http://dtach.sourceforge.net/

wired:

well, if your needs are satisfied with dtach, then sure, the others are bloatware for you! I, on the other hand, actually use their features

ΤΖΩΤΖΙΟΥ:

I don't know why your 'screen' use is bloated. This is from a 256 MiB home server:

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
1 S tzot 3215 1 0 80 0 – 1319 ? May01 ? 00:00:03 SCREEN -A -a -U
0 S tzot 32215 32214 0 80 0 – 1018 ? 11:32 pts/0 00:00:00 screen -A -a -U -D -r 321

Its size is 100×25, four bash/dash sessions plus one mc session, no ~/.screenrc, the default /etc/screenrc has defscrollback 1000. The system runs gentoo on a Geode LX processor.

fb:

I originally switched from screen to tmux because screen has problems with terminals larger than 256 chars in width. Maybe there are patches around, but I couldn't find a solution back then (I don't think they solved it until now?). Anyway, tmux works find with >256 char wide terminals . And soon I realized how much "better" tmux is.

nice seeing you switching to tmux too

ed:

screen is really cool, and does somethings that I've yet to find counterparts to with tmux, such as the -x option:

http://www.s5h.net/wiki/Screen#Automation

How did you measure the RAM usage? Did you have the same scrollback in tmux as screen?

nm:

The equivalent of -x is the default with tmux unless you explicitly tell it to detach other sessions. You can also create a grouped session with "tmux new -t othersession" if you want them to have different a current window.

All of the stuff at that link is possible in tmux and is often much easier…

[Sep 15, 2009] The Many Uses of Screen By Juliet Kemp

September 11, 2009 | ServerWatch.com

Monitor a window for output: Hit Ctrl-A Shift-M when in window 1, and then flip to window 2 (with Ctrl-A N), and you'll be notified in window 2 when there's output in window 1. This is useful if you're running a job that takes a long time; no need to keep flipping between windows. You can also monitor for silence with Ctrl-A _. This is useful if you're running a compile job or something else that outputs a lot of stuff when it's running successfully.

Selected comments

By berto September 15 2009 2:26 PMPDT

the one i use ;)

@bertocasa (amelgar) ~ :: cat .screenrc
#kill startup message
startup_message off

defscrollback 1024
hardstatus on
hardstatus alwayslastline

#hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}% w %=%{..G} %H %{..Y} %m/%d %C%a "

hardstatus string '%{= kg}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?% Lw%?%?%= %{g}]%{=b C}[ %d %M %c ]%{W}'

screen -t rOOt 0 su -
screen -t ncmpc 1 bash
screen -t terminal 2 bash
screen -t MComander 3 mc
screen -t vimTerm 4 bash
screen -t terminal 5 bash
screen -t dropbox 6 bash

[Sep 15, 2009] Cut and Paste With Screen By Juliet Kemp

September 8, 2009 | ServerWatch.com

To enter copy mode in screen, hit Ctrl+A, then [. You can now use the arrow keys, or vim-like keybindings, to move around the screen. 0 gets you to the start of a line, and $ to the end of a line.

  1. When you've reached the point where you want to start the copy, hit Enter.
  2. Move the cursor to the end point of your selection (you'll see what you're copying highlighted), and then hit Enter again.
  3. Now move the cursor to wherever you want to paste the selection (you can move to another screen within your session), and hit Ctrl+A ] to paste the selection.

You can also use Ctrl+A > filename to paste the selection to a filename and Ctrl+A < filename to read a file into the selection buffer so you can then paste it out again using Ctrl+A ].

When in copy mode, you can also use screen's scrollback feature (i.e., you can scroll back upward past the top of the currently displayed text) and the search function.

Use ? to search backward. This is probably what you want initially, as you'll be starting by default from the bottom of the scrollback.

/ searches forward.

Bear in mind that the default scrollback is only 100 lines. To increase this, add a line to your ~/.screenrc:

defscrollback 1000

[Jul 11, 2009] Screen (vim + gnu screen) - Start gnu screen w- your vim session and a split shell + send commands to the sh vim online

created by Eric Van Dewoestine

Screenshot: http://eclim.sourceforge.net/_images/screenshots/vim/gnu_screen_shell.png

Note: gvim is not supported. You must be running vim in a console.

Currently tested on Linux and cygwin, but should work on any unix based
platform where screen is supported (OSX, BSD, Solaris, etc.). Note that
in my testing of cygwin, invocations of screen were significantly slower
and less fluid than on Linux.

This plugin aims to simulate an embedded shell in vim by allowing you to
easily convert your current vim session into one running in gnu screen
with a split gnu screen window containing a shell, and to quickly send
statements/code to whatever program is running in that shell (bash,
python, irb, etc.).

Commands:
:ScreenShell [cmd] - Opens the split shell by doing the following:
1. save a session file from your currently running vim instance
(current tab only)
2. start gnu screen with vim running in it
3. load your saved session file
4. create a lower gnu screen split window and start a shell
5. if a command was supplied to :ScreenShell, run it
Ex. :ScreenShell ipython

Note: If you are already in a gnu screen session, then only steps
4 and 5 above will be run.

:ScreenSend - Send the visual selection or the entire buffer contents to
the running gnu screen shell window.

:ScreenQuit - Save all currently modified vim buffers and quit gnu
screen, returning you to your previous vim instance
running outside of gnu screen
Note: :ScreenQuit is not available if you where already in a gnu
screen session when you ran :ScreenShell.
Note: By default, if the gnu screen session was started by
:ScreenShell, then exiting vim will quit the gnu screen session
as well (configurable via g:ScreenShellQuitOnVimExit).

An example workflow may be:
Open a python file to work on:
$ vim something.py

Decide you want to run all or pieces of the code in an interactive
python shell:
:ScreenShell python

Send code from a vim buffer to the shell:
:ScreenSend

Quit the screen session and return to your original vim session:
:ScreenQuit
or
:qa

Gotchas:
- While running vim in gnu screen, if you detach the session instead of
quitting, then when returning to the non-screen vim, vim will complain
about swap files already existing. So try to avoid detaching.
- Not all vim plugins support saving state to or loading from vim
session files, so when running :ScreenShell some buffers may not load
correctly if they are backed by such a plugin.

install details

Download the script and put it in your plugin directory (~/.vim/plugin).

[Jul 8, 2009] Useful Tricks With Screen

screen is a very useful program which in effect gives you multiple console screens in the same window. It's handy if you're using a console rather than an xterm, or if you're connected to another machine, as it means you can do multiple things u're working remotely: If your connection falls over while you're still in a screen session, you can ssh back to the machine and reattach the screen (with screen -r) and get straight back to where you were, rather than having to start over.

You can also manually detach the screen, with screen -d (detach screen), or by hitting Ctrl-A then D while in a screen session. This leaves the screen running in the background, and it can be useful for running background jobs. Or you can leave a screen session connected to another machine: Run screen before you open the ssh session, then instead of logging out when you're done, detach the screen, and then just reattach it (screen -r) when you need to connect to that machine again. The downside of this is that it does have security implications!

Recent Tips
" xclip: Command-Line Clipboard
" Make It Snappy With Vim
" Unicode Characters in Vim

Read All Tips of the Trade

A final screen trick enables you to remotely look over a user's shoulder if you're trying to fix a problem. 

xclip /path/to/file
Log on to the user's machine as him, then type 
screen -S debug
Then, get him to type 
screen -x debug
and he'll join your screen session. After this, whatever he does will be replicated on your screen (and vice versa). ('debug' is the identifier; any other name would also be fine.) This can save a lot of time when trying to track down a problem or to explain a solution!

[Jul 7, 2009] tmux 0.9

tmux is a "terminal multiplexer". It allows a number of terminals (or windows) to be accessed and controlled from a single terminal. It is intended to be a simple, modern, BSD-licensed alternative to programs... such as GNU screen

Red Hat Magazine A guide to GNU Screen

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:

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@myserver

On 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:

[June 1, 2009] Screen – Manages multiple sessions on one terminal Ubuntu Geek

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

[Sep 12, 2008] Index of Screen for AIX (precompiled RPM)

screen-4.0.3-1.aix5.1.ppc.rpm 30-May-2008 20:58 548K

[Sep 11, 2008] The LXF Guide 10 tips for lazy sysadmins Linux Format The website of the UK's best-selling Linux magazine

screen: detach to avoid repeat logins

Entering:

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 -r

and 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 debug

Then get them to type:

screen -x debug

and 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.)

[Jun 26, 2008] The latest version of Sven Guckes screen setup is available at http://www.guckes.net/Setup/screenrc

# =====================================================================
# 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
# ==========================================================================

[Mar 12, 2008] Terminator - Multiple GNOME terminals in one window

Rewrite of screen in Python?

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 <[email protected]>

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.

Using GNU screen's multiuser feature for remote support

Re: Using GNU screen's multiuser feature for remote support

Posted 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:04

[ Send Message ]

That 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

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):

Re binding ctrl-arrow

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.

Re Screen and Linux box characters

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

Re sorting screens

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

[Nov 08, 2007] screen patch

Vi style mode for screen
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 Dunford

screen-4.0.2.diff
Description: Text Data

New screen features -- groups

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?

Re how to send commands to running screen sessions

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 ,)

RE: how to send commands to running screen sessions

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

[Nov 07, 2007] New screen features available

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);}

A Patch for Vertical Split for GNU Screen

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 <[email protected]> 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:

SourceForge.net Screen Window Manager (Screenwm)

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.

Red Hat Magazine A guide to GNU Screen

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
Speaking 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

[Sep 28, 2007] Screen Tips & Tricks by Łukasz Olender

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 ~/.screenrc one 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, press C-a A and 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 press C-a : and enter the following command screen [program name] (this is the way you enter all commands during the screen session). To go to the next tab press C-a n and to return to the previous one press C-a p. To switch between the tabs use C-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 press C-a [Tab]. You have to create a new shell in the new window, so press C-a c. You can create more regions by pressing C-a S more 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 entering resize [size], where size is the number of lines.

Two windows filling whole the display with screen splitted into two regions
Img. 1 Two windows filling whole the display with screen split into two regions

4. 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 pressing C-a :. Below I include one of configuration files which causes splitting a window into two regions and running ekg in the top one.

As 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:

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 none in 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 lockscreen or the shortcut C-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.

[Jul 19, 2007] Screen The terminal baby-sitter in the sysadmin's toolbox

...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 radiostation

If 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.

More on this topic
Find other admin tips on SearchEnterpriseLinux.com

Tony Mancill on the 'lost art of named pipes'

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/146

As 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.

[Jul 19, 2007] The Screen Program - Linux Forums

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 

screen

Begin the tarring and bzipping. 

tar -cf enormous_directory.tar && bzip2 enormous_directory.tar

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 -ls

This 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-username

The 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 6795

and 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 tarbzip

Begin 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-username

So, 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+S

The 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.

[Jul 15, 2007] SCREEN explained by Sven

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).
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. ;-)
Summary: Start SCREEN before starting any other commands. It'll be well worth it.

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.

Power Sessions with Screen Linux Journal by Adam Lazur

Sessions

Now 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 Mode

One 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 screenrc

I 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.log

If 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 19200

If 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.

freshmeat.net Project details for screen

["] Fix for backspace problem on some systems
by devel at hastek - Sep 25th 2003 23:49:59

I 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

Guide to a happier unix life - screen (Ask Bjørn Hansen)

emad:

I agree. Screen is great.

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.

Posted by: emad | February 8, 2006 9:56 AM

Posted on: February 8, 2006 09:56

Uzair:

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}.

Tutorial Use GNU Screen (in UNIX)

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,
Sam

Posted 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 user2

Now 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

The Unix Screen Utility

Short description. It is lucking split feature.

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.

[Jul 10, 2007] BigAdmin Feature Article Installing and Using GNU Screen by Amy Rich

Precompiled package for screen is available from http://www.sunfreeware.com/

Common Screen Tasks

Starting and Selecting Windows

Once screen is installed, it can be used without any further configuration. First run /usr/local/bin/screen to 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 command screen. 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 sequence Ctrl-a :. Once in command mode, type in screen and 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 for Ctrl-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/next mechanism 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 sequence Ctrl-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 sequence Ctrl-a # where # is the number of the window. For example, if there were a shell running in window 2, switch to it using Ctrl-a 2. To see a listing of all virtual windows and select one to switch to, enter Ctrl-a ". To hop back to the window last displayed, enter Ctrl-a Ctrl-a.


History, Cut and Paste, Logging, and Monitoring

When 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 sequence Ctrl-a Ctrl-].

Activity in a screen virtual window can be logged to a file, much like the UNIX script command does for an interactive session. To toggle logging of activity in the window to the file screenlog.#, where # is a number starting at 0, enter the key sequence Ctrl-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 sequence Ctrl-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 sequence Ctrl-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 -ls from the command line. On a machine called hostname where the user username is 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.hostname run 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.hostname

If there was only one active session, screen could be called without the session name:

screen -d 
screen -D

There 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 screen program:

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 -ls command and can be cleaned out with the screen -wipe command.

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:

[Jun 20, 2007] Gentoo Linux Dume ntation -- Keychain

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.

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.

screen-faq: How do I display the window number and other things in the status line?

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).

[Jun 6, 2007] GNU Screen - the ASCII window manager - Linux Forums

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.

[Jun 4, 2007] Deadman.org SSH-Agent Forwarding and GNU Screen

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.

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 22

The 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/fixssh

The 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

[Jan 1, 2007] GNU screen and SSH

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.

kuro5hin.org Comments GNU Screen an introduction and beginner's tutorial

Splitvt... (none / 3) (#112)
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)
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

GNU stuff tends to be user hostile, but +1 still (none / 2) (#38)
by codeboy on Wed Mar 10, 2004 at 04:16:27 AM EST

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 use screen -x instead of screen -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 that

2) 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.

Modern life, in EVERY ASPECT, is a cult of mediocrity.-trhurler

use ctrl-\ instead of ctrl-a, and remap caps lock (none / 2) (#172)
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.

Will you squirm when you are pecked? Quack.

How I use it (3.00 / 6) (#115)
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).

making it go away (none / 2) (#118)
by mikpos on Thu Mar 11, 2004 at 10:19:55 AM EST
Ctrl-a \ or Ctrl-a Ctrl-\ by default will kill screen and all its windows. However, in the default config file (this isn't nearly confusing enough), I believe these are rebound to do nothing, with a comment saying that they are "dangerous".

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)
by static on Thu Mar 11, 2004 at 09:53:29 PM EST
First of all, a lot of readers don't realize that using screen to multiplex an xterm is actually a subtly different solution than starting a dozen xterms. The difference is that in screen you can select the screen you want directly. Doing that with all your xterms requires assistance from your window manager. Or a term program (like Konsole) that has tabbing et al.

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)
by BranchingLichen on Sun Mar 14, 2004 at 12:06:16 AM EST
Rather than using Ctrl-A N and Ctrl-A P, I'd like to use Ctrl-Tab and Ctrl-Shift-Tab to switch to the next / previous screen.

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)
by benley on Sun Mar 14, 2004 at 10:06:10 PM EST
Well, I don't know about ctrl-tab, but here's what I have in my screenrc to enable ctrl-left and ctrl-right selection of previous and next screen windows:

#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"
hardstatus alwayslastline "%{-b gk}%-w%{+b kg}%50>%n %t%{-b gk}%+w%<"

(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?

You can also do a similar trick with 'script'.

[ Parent ] screen is essential for heavy irc use (none / 0) (#189)
by akuzi on Thu Apr 01, 2004 at 06:45:32 PM EST

It lets you sit on an irc channel forever and yet connect in from anywhere on the net, scroll back to set what has been happening on the channel etc.

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)
by tim on Fri Apr 16, 2004 at 04:31:31 PM EST

I absolutely loved screen back in my university days. I would be hacking at the lab at school until it was late enough that I wanted to go home. Then I would just detach my screen, go home, login and reattach the screen and I would be right back in the same place. Sadly I don't find much use for it these days.

tbc GNU screen and SSH

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 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.

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.

[Jun 10, 2006] GNU Screen by Jonathan McPherson

Nice tutorial.

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.

[Jun 10, 2006] eater.org-blog GNU Screen Hackery

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

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019