Attaching to and detaching from screen sessions

Screen is a "must" tool for Unix Administrators

• Introduction
• Authodetach capability
• Detaching and reattaching
• To join a screen that is already attached
• Naming screen sessions
• Summary

Introduction

 GNU Screen is a simple, but at the same time flexible and programmable windows manager. It is often called terminal multiplexer, but the key functionality of screen is in the area of windows management: creation, destruction and resizing of windows.  For example it can split the console screen horizontally and display two windows at the same time.  Screen is a Unix program (Cygwin version exists and is quite usable). For good Windows terminal emulator see Teraterm

Authodetach capability

One of the most important) feature of screen is that like VNC it provides the ability to detach the terminal emulator from the running programs and then reattach the same or new terminal to them.

Autodetach setting might not be enabled by default so it make sense to put a corresponding directive in your .screenrc

autodetach on

Detaching and reattaching

You can detach just by closing the terminal emulator that contains the session. Neither of these actually end your session. All they do is unbind your session from the current terminal. All of the programs you started running within screen are still running.

To detach a session, use Ctrl-a d. If that's the only session running (which is typical for novices) you can reattach with Ctrl-a r.

To reattach outside the screen type

screen -r 

You can also use the command:

screen -x

If more than one session is detached, you'll need to provide session PID that you can obtain by listing sessions with the command screen -ls

you can attach with just the pid i.e. screen -r 12345

To join a screen that is already attached

use:

screen -x screenid

For example

screen -x 29878.pts-6.myuserid

Will attach you to that screen. In this case you have two session for the same UserID. Both users have control so be careful.

Naming screen sessions

Assuming you want named sessions for clarity, you can name a session in screen by starting screen as:

screen -U -S session_name

You can then reattach to a session using:

screen -R session_name

or kill/quit a session using:

screen -S session_name -X quit

Summary

List  available screen sessions

screen -ls

Reconnect to specific session

• If there is a single session only screen -x will suffice.
• Otherwise you need to provide the name of the screen session

screen -D -R main

Connect to specific session in "watching/spy mode"

screen -x screen_session_name

If there is a single session only screen -x will suffice.

you can attach with just the pid i.e. screen -r 12345

Reattaching to session within the screen

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.

Dr. Nikolai Bezroukov

NEWS CONTENTS

• 20191212 : command line - Reattaching to an existing screen session - Ask Ubuntu ( Jan 01, 2013 , askubuntu.com )
• 20181102 : How to Recover from an Accidental SSH Disconnection on Linux RoseHosting ( Nov 02, 2018 , www.rosehosting.com )
• 20181102 : [Solved] screen autodetach problem ( The FreeBSD Forums )
• 20120123 : A guide to GNU Screen by Steve 'Ashcrow' Milner and Anderson Silva ( October 5, 2007 Red Hat Magazine )
• 20101019 : Make GNU Screen Your Default Shell ( October 18 2010 , ServerWatch.com )
• 20101019 : Taking Command of the Terminal with GNU Screen by Joe 'Zonker' Brockmeier ( February 11, 2010 , linux.com )
• 20100627 : Screen - s5h.net ( Screen - s5h.net, Jun 27, 2010 )
• 20100627 : switching from gnu screen to tmux (updated) ( Linux~ized )
• 20090915 : The Many Uses of Screen by Juliet Kemp ( September 11, 2009 , ServerWatch.com )
• 20090711 : Screen (vim + gnu screen) - Start gnu screen w- your vim session and a split shell + send commands to the sh vim online ( Screen (vim + gnu screen) - Start gnu screen w- your vim session and a split shell + send commands to the sh vim online, Jul 11, 2009 )
• 20090708 : Useful Tricks With Screen ( Useful Tricks With Screen, Jul 8, 2009 )
• 20090707 : tmux 0.9 ( tmux 0.9, Jul 7, 2009 )
• 20090707 : Red Hat Magazine A guide to GNU Screen ( Red Hat Magazine A guide to GNU Screen, )
• 20090601 : Screen – Manages multiple sessions on one terminal Ubuntu Geek ( Screen – Manages multiple sessions on one terminal Ubuntu Geek, June 1, 2009 )
• 20040212 : Curiosity is bliss Essential utility screen ( Curiosity is bliss Essential utility screen, Feb 12, 2004 )
• 20040212 : macosxhints.com - Use screen as a serial terminal emulator ( macosxhints.com - Use 'screen' as a serial terminal emulator, )

Old News ;-)

[Dec 12, 2019] command line - Reattaching to an existing screen session - Ask Ubuntu

Jan 01, 2013 | askubuntu.com

Reattaching to an existing screen session Ask Question Asked 6 years, 6 months ago Active 1 year, 3 months ago Viewed 262k times

---

JohnMerlino , 2013-06-01 01:39:54

I have a program running under screen. In fact, when I detach from the session and check netstat, I can see the program is still running (which is what I want):

udp        0      0 127.0.0.1:1720          0.0.0.0:*                           3759/ruby

Now I want to reattach to the session running that process. So I start up a new terminal, and type screen -r

$ screen -r
There are several suitable screens on:
    5169.pts-2.teamviggy    (05/31/2013 09:30:28 PM)    (Detached)
    4872.pts-2.teamviggy    (05/31/2013 09:25:30 PM)    (Detached)
    4572.pts-2.teamviggy    (05/31/2013 09:07:17 PM)    (Detached)
    4073.pts-2.teamviggy    (05/31/2013 08:50:54 PM)    (Detached)
    3600.pts-2.teamviggy    (05/31/2013 08:40:14 PM)    (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

But how do I know which one is the session running that process I created?

Now one of the documents I came across said:

"When you're using a window, type C-a A to give it a name. This name will be used in the window listing, and will help you remember what you're doing in each window when you start using a lot of windows."

The thing is when I am in a new screen session, I try to press control+a A and nothing happens.

Paul ,

There are two levels of "listings" involved here. First, you have the "window listing" within an individual session, which is what ctrl-A A is for, and second there is a "session listing" which is what you have pasted in your question and what can also be viewed with screen -ls .

You can customize the session names with the -S parameter, otherwise it uses your hostname (teamviggy), for example:

$ screen

(ctrl-A d to detach)

$ screen -S myprogramrunningunderscreen

(ctrl-A d to detach)

$ screen -ls

There are screens on:
    4964.myprogramrunningunderscreen    (05/31/2013 09:42:29 PM)    (Detached)
    4874.pts-1.creeper  (05/31/2013 09:39:12 PM)    (Detached)
2 Sockets in /var/run/screen/S-paul.

As a bonus, you can use an unambiguous abbreviation of the name you pass to -S later to reconnect:

screen -r myprog

(I am reconnected to the myprogramrunningunderscreen session)

njcwotx ,

I had a case where screen -r failed to reattach. Adding the -d flag so it looked like this

screen -d -r

worked for me. It detached the previous screen and allowed me to reattach. See the Man Page for more information.

Dr K ,

An easy way is to simply reconnect to an arbitrary screen with

screen -r

Then once you are running screen, you can get a list of all active screens by hitting Ctrl-A " (i.e. control-A followed by a double quote). Then you can just select the active screens one at a time and see what they are running. Naming the screens will, of course, make it easier to identify the right one.

Just my two cents

Lefty G Balogh ,

I tend to use the following combo where I need to work on several machines in several clusters:

screen -S clusterX

This creates the new screen session where I can build up the environment.

screen -dRR clusterX

This is what I use subsequently to reattach to that screen session. The nifty bits are that if the session is attached elsewhere, it detaches that other display. Moreover, if there is no session for some quirky reason, like someone rebooted my server without me knowing, it creates one. Finally. if multiple sessions exist, it uses the first one.

Much kudos to https://support.dvsus.com/hc/en-us/articles/212925186-Linux-GNU-Screen-instructions for this tip a while back.

EDIT:

Also here's few useful explanations from man screen on cryptic parameters

       -d -r   Reattach a session and if necessary detach it first.

       -d -R   Reattach a session and if necessary detach or  even  create  it
               first.

       -d -RR  Reattach  a  session  and if necessary detach or create it. Use
               the first session if more than one session is available.

       -D -r   Reattach a session. If necessary  detach  and  logout  remotely
               first.

there is more with -D so be sure to check man screen

tilnam , 2018-03-14 17:12:06

The output of screen -list is formatted like pid.tty.host . The pids can be used to get the first child process with pstree :

screen -list|cut -f1 -d'.'|cut -f2|xargs -n 1 pstree -p|grep "^screen"

You will get a list like this

screen(5169)---zsh(5170)---less(15268)
screen(4872)---zsh(4873)-+-cat(11364)
...

> ,

screen -d -r 4964

or

screen -d -r 4874

---

$ screen -ls
There are screens on:
4964.myprogramrunningunderscreen    (05/31/2013 09:42:29 PM)    (Detached)
4874.pts-1.creeper  (05/31/2013 09:39:12 PM)    (Detached)
2 Sockets in /var/run/screen/S-paul.

[Nov 02, 2018] How to Recover from an Accidental SSH Disconnection on Linux RoseHosting

Nov 02, 2018 | www.rosehosting.com

... I can get a list of all previous screens using the command:

screen -ls

And this gives me the output as shown here:

As you can see, there is a screen session here with the name:

pts-0.test-centos-server

To reconnect to it, just type:

screen -r

And this will take you back to where you were before the SSH connection was terminated! It's an amazing tool that you need to use for all important operations as insurance against accidental terminations.

Manually Detaching Screens

When you break an SSH session, what actually happens is that the screen is automatically detached from it and exists independently. While this is great, you can also detach screens manually and have multiple screens existing at the same time.

For example, to detach a screen just type:

screen -d

And the current screen will be detached and preserved. However, all the processes inside it are still running, and all the states are preserved:

You can re-attach to a screen at any time using the "screen -r" command. To connect to a specific screen instead of the most recent, use:

screen -r [screenname]

Changing the Screen Names to Make Them More Relevant

By default, the screen names don't mean much. And when you have a bunch of them present, you won't know which screens contain which processes. Fortunately, renaming a screen is easy when inside one. Just type:

ctrl+a :

We saw in the previous article that "ctrl+a" is the trigger condition for screen commands. The colon (:) will take you to the bottom of the screen where you can type commands. To rename, use:

sessionname [newscreenname]

As shown here:

And now when you detach the screen, it will show with the new name like this:

Now you can have as many screens as you want without getting confused about which one is which!

---

If you are one of our Managed VPS hosting clients, we can do all of this for you. Simply contact our system administrators and they will respond to your request as soon as possible.

If you liked this blog post on how to recover from an accidental SSH disconnection on Linux, please share it with your friends on social media networks, or if you have any question regarding this blog post, simply leave a comment below and we will answer it. Thanks!

[Solved] screen autodetach problem

The FreeBSD Forums

kattenjanson
Junior Member Join Date: Mar 2011
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts

screen autodetach problem

--------------------------------------------------------------------------------

Hi!

I have come across a rather annoying problem running screen under FreeBSD. It seems that whenever I forget detaching the session properly (I usually ssh from a windows machine using putty), it runs for a few hours after which session hangs. When running screen -ls, the session is listed as attached. Doing screen -D sometimes generates the output that screen has been power-detached, although when I run screen -ls once more - it lists the session as still attached. I have of course read the manual but no option seems to help (been trying a few different flags for resuming screen). My .screenrc is a rather simple one (i.e, the only thing I have changed from defaults is the status bar and button-bindings).

I am usually able to solve these problems myself and I have been looking through forums and googled the issue but I am unsure how to proceed troubleshooting. Any advice or the like would be greatly appreciated!

--------------------------------------------------------------------------------
Last edited by DutchDaemon; March 2nd, 2011 at 01:14. Reason: It's "I": http://en.wikipedia.org/wiki/Capitalization#Pronouns

kattenjanson
View Public Profile
Send a private message to kattenjanson
Find all posts by kattenjanson

#2 March 1st, 2011, 23:03
gordon@
FreeBSD Developer Join Date: Feb 2008
Location: San Diego, CA

I don't bother detaching the other session, just use screen -x.

gordon@
View Public Profile
Send a private message to gordon@
Find all posts by gordon@

#3 March 2nd, 2011, 10:28
kattenjanson
Junior Member Join Date: Mar 2011

--------------------------------------------------------------------------------

Yes, I have tried this as well, although to no avail. It seems that the same problem occurs under archlinux. I might have used the wrong topic, btw. The real issue is that when not detaching properly, the session runs for about 4 or 5 hours then dies. I noticed this when my irssi session pinged out after about the same time. What happens is, I cannot attach the session at all after this has happened.

--------------------------------------------------------------------------------
Last edited by DutchDaemon; March 2nd, 2011 at 17:57.

kattenjanson
View Public Profile
Send a private message to kattenjanson
Find all posts by kattenjanson

#4 March 3rd, 2011, 11:21
mix_room
Member Join Date: Aug 2009
Posts: 371
Thanks: 8Thanked 26 Times in 24 Posts

--------------------------------------------------------------------------------

What I do:

Code:
log on using SSH (eg Putty)
if (screen_is_running)
screen -x
else
screen
endif
logout (ie. close PuTTy session)This works wonderfully under FreeBSD, my sessions have been inactive for weeks without problems.

How are you closing the connection?

mix_room
View Public Profile
Send a private message to mix_room
Find all posts by mix_room

#5 March 4th, 2011, 20:21
kattenjanson
Junior Member Join Date: Mar 2011
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts

--------------------------------------------------------------------------------

The sessions are mainly closed when the lid on my laptop is closed it seems that screen -x works a bit better than screen -Dr or -dr btw. Not without problems, though, as the problem with irssi persists. When im able to resume the session, alot of the time irssi has simply stopped working and doesnt accept input. When i kill the "window" in which irssi is running, the other "windows" in screen seems to completely stop responding as well (even though they accepted input before killing the irssi-window). I realize that this is not a great problem since having a irc-session running 24/7 might not be the most important thing, but i am rather curious as to why this is happening.

kattenjanson
View Public Profile
Send a private message to kattenjanson
Find all posts by kattenjanson

#6 March 4th, 2011, 20:46
wblock@
FreeBSD Developer Join Date: Sep 2009
Location: Milky Way galaxy
Posts: 4,234
Thanks: 124
Thanked 789 Times in 707 Posts

--------------------------------------------------------------------------------

Some people mention sysutils/tmux as a new alternative to sysutils/screen.

wblock@
View Public Profile
Send a private message to wblock@
Visit wblock@'s homepage!
Find all posts by wblock@

#7 March 4th, 2011, 21:30
bes
Junior Member Join Date: Aug 2010
Posts: 76
Thanks: 4
Thanked 28 Times in 25 Posts

--------------------------------------------------------------------------------

I like tmux better than screen.There is a pretty good tutorial online that even has purty pictures.

bes
View Public Profile
Send a private message to bes
Find all posts by bes

#8 March 7th, 2011, 11:57
kattenjanson
Junior Member Join Date: Mar 2011
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts

--------------------------------------------------------------------------------

Thank you very much for the help, all of you, greatly appreciated! Tmux works very well.

[Jan 23, 2012] A guide to GNU Screen by Steve 'Ashcrow' Milner and Anderson Silva

October 5, 2007 Red Hat Magazine

Sharing a session with others

Another great application of Screen is to allow other people to login to your station and to watch the work you are doing. It is a great way to teach someone how to do things on the shell.

Setup to allow screen to be shared

1. As root: chmod u+s /usr/bin/screen (Screen has to be SUID if you want to share a term between two users.)
   Note: SUID allows an executable to be run by the owner of that file, instead of with the user's own permission. There are some security concerns when doing this, so use this tip at your own discretion.
2. chmod 755 /var/run/screen
3. Log out of root, and run Screen as the user who is going to share the session:
   screen
4. Press Ctrl+a, then type :multiuser on and press Enter.
5. Press Ctrl+a, then type :acladd steve ("steve" is the username of the person who will connect to your screen session).

Connecting to the shared screen:

1. SSH into the workstation that you are going to watch the screen session on.
2. On your terminal type: screen -x anderson/ ("anderson" is the username of the person who is sharing the screen session. You need the / at the end.).

And now both users (from the host and guest) will be sharing a screen session and can run commands on the terminal.

Working from multiple locations

Let's say you have a screen session open at work with X number of windows on it. Within those screens you may be running an IRC client, an SSH connection to the web server, and your favorite text-based email client. It's 5 p.m. and you have to go home, but you still have work left to do.

Without Screen you would probably go home, VPN into your company's network, and fire up all the shells you need to keep working from home. With Screen, life gets a little easier.

You can simply SSH into your workstation at work and list your available screen sessions with the command:

screen -ls

And connect to the sessions you were running at work with the command:

screen -x screen_session_name

This way screen will let you pick things up exactly from where you left off.

Applications to make Screen your window manager

Now that you have seen what Screen can do for you, you probably are wondering how to make it your main interaction point, like a terminal window manager.

Let's start with IRC, a very common and popular chat system. Instead of using a graphical client like Pidgin, install Irssi. Irssi sports a slick console interface, tons of add-ons and scripts, and can be enhanced with Perl. It's even theme-able!

Another important part of any user's setup is email. Today most people use graphical clients such as Thunderbird, Evolution, or Sylpheed. My favorite client happens to run in a terminal: Mutt. While Mutt isn't the easiest client in the world to set up, it sure is a joy to use. You can even use your favorite console text editor for doing emails.

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. Vim is a powerful text editor which, as is stated on the Vim website, could be considered an entire IDE in itself and sports syntax coloring in over 200 programming languages. If Vim doesn't fit your style, there is always emacs, nano, or JOE.

Now all you need you need to do is edit your ~/.screenrc to meet your needs.

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

Once you get used to the shortcuts in GNU screen, not only will your desktop become more organized (due to the lower number of open windows), but your efficiency as a developer or system administrator will increase not only at work but at your home office as well.

Richard :

Just like abeowitz, I'm wondering whether it is possible to use screen to send commands to multiple screens.

According the documentation this should be possible with the "at" command, but I don't get it to work.

So the command sequence:
C-a :at # date
Should result in a date executed on all windows (to my understanding, but the result I get is:
": at: at least two arguments required")

OTOH according the TODO file at:
ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-4.0.3.tar.gz
states: "- type into several windows at once (for cluster admins)"
That file has been changed in august 2003 for the last time…

Hopefully someone reading this article knows how to use the at command???

Hey Richard!:

With the 'at' command, you can send commands to other windows that have to be typed when you press C-a :
This changes the title of a window in a certain screen session:
screen -X at 1 title blublublu

Richard:

A way to broadcast commands to all windows is the following:
^a:at \# stuff "ls12?

Thanks goes to Michael, (one of the screen devs) who provided this information to me.The command above should read: double quote ls backslash zero twelve double quote. Somehow the parser removes the blackslash zero. One more try:
^a:at \# stuff "ls\\12″

Rob Nichols:

This is a great intro. I've used screen for many years. (Just stopped to count. I think it's been a decade!) However, I'd never bothered with learning about the hardstatus line until this article. It's a nice addition. Thanks!

P.S. I think there are two mistakes in the example given. Again, this is my first foray in screen's string escapes, so I might be way off. I think "%{=kw}" should have a space, as "%{= kw}". Without this change on my system windows before the current are green instead of white. I also think there is an extra "%?" before the the closing "]" on the window list. This made no difference on my system. Here's a version with these changes.

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}]'

John:

I've used Screen for more than a decade. For years now I've used it to keep open ssh sessions to various systems, doing things like tailing logs and such, and disconnecting then reconnecting when necessary. My latest session has been running upwards of 2 years, only ever bringing it down for critical patching. Sometimes I connect to the same session from multiple windows, displaying different screen "windows" for multiple views. I also use an always on statis as well.

The few modifications I've made are to increase the MAXWIN param to allow for more windows, and change the command key to ^w so I don't have to unlearn my emacs ^a habits.

John Pye:

One good use of Screen is when performing remote updates of systems using apt-get or yum. You can start the update going, then disconnect, then come back later and check that it finished OK. If your remote connection goes down, it doesn't mess everything up. Also, using the screen 'logging' function, you can keep a full history of the update, and check it for error messages that you might have missed.

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

pbrisbin

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.

• Start Screen: screen
• Detatch Screen: Ctrl-a d
• Re-attach Screen: screen -x or screen -x PID
• Split Horizontally: Ctrl-a S
• Split Vertically: Ctrl-a |
• Move Between Windows: Ctrl-a Tab
• Name Session: Ctrl-a A
• Log Session: Ctrl-a H
• Note Session: Ctrl-a h

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.

[Jun 27, 2010] Screen - s5h.net

[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

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

• Make a hardstatus line. This is basically a line at the bottom of the screen that lists your current terminal and all opened ones. It can also display the system clock and the hostname.
• Default screens on startup. It's quite nice to have your IRC connection, mail client, and default SSH connections auto-start for you!

The lines below are numbered for reference. Your config file should not have numbered lines.

1 hardstatus alwayslastline
2 hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{=kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B}%Y-%m-%d %{W}%c %{g}]'
3
4 # Default screens
5 screen -t shell1	0
6 screen -t shell2	1
7 screen -t server	2	ssh me@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

[Feb 12, 2004] Curiosity is bliss Essential utility screen

Screen is a command line utility that comes with lots of Unix variants (including Linux). It is a bit hard to describe and to discover. It provides two main features: multiplexing a terminal and detaching/re-attaching sessions.

I originally got shown this by my "System programming" TA, when I asked him if I could disconnect X11 application from one terminal and have them re-open (in the same state) onto another terminal. It turns out this is possible for X11 applications (see xmove or xmx, proxy-based redirections, or guiEvict <via sweetcode>, described in this paper). But "screen" although limited to text applications is so useful that I dropped my search for its X11 equivalent.

Multiplexing: If you start a remote shell (say SSH) but want to do more than one thing at a time, you may want to open more sessions, but you can also use screen. It allows you to switch between multiple shells on the same connection.
You need to first run "screen", then use "Ctrl-A Ctrl-C" (control A, control C) to create a new shell, and you now can switch between shells with "Ctrl-A Ctrl-*" where * is the number for you shell (for ex, use "Ctrl-A Ctrl-1" to switch to shell 1).

Session migration: Let's say you need to disconnect from that session, but you want to continue it from another computer. You can use "Ctrl-A Ctrl-D" to detach screen. All the shells will be maintained, and you can reconnect to the remote machine again and type "screen -R" to re-attach to the original session. This is also very useful in can the connection is lost by accident.

macosxhints.com - Use 'screen' as a serial terminal emulator

I often have to do router configuration via a console port, so I use a Keyspan Serial Adapter to get access. Two problems then present themselves:

1. ZTerm is a horrible Mac OS X app. It hasn't been updated in five years or so, and isn't a Universal Binary. The developer doesn't seem in any hurry to rectify the situation. It is not worth the shareware fee in its current form.
2. Minicom requires installation of Fink or MacPorts and is overly complex.

Solution: Use screen, Terminal, and a little AppleScripting.

First, launch Script Editor and type/paste in the following code:

tell application "Terminal" do script with command "screen /dev/tty.KeySerial1" set number of rows of window 1 to 100 set number of columns of window 1 to 80 set background color of window 1 to "black" set normal text color of window 1 to "green" set custom title of window 1 to "SerialOut" end tell

Compile and save as an app from within Script Editor, and you have a double-clickable application to launch a serial Terminal session. You may want to customize this slightly -- you can change the screen colors or number of columns or rows. You may also need to customize the screen command with a different device name if you are using something other than the Keyspan Serial Adapter (do an ls tty* of the /dev/ directory to get the right name).

screen uses Control-A to take commands directed to it. So type Control-A followed by Control-\ to exit your screen session. If you fail to do this and exit a Terminal session, you'll leave the screen session alive and the serial resource unavailable until you kill the screen session manually. man screen will show you further commands to send to a screen session.

If anyone can reply with a link to a tutorial on how to wrap an interactive Unix App in Cocoa, that would be the next step -- it would be nice to do this without involving Terminal. If you prefer to use Minicom, you could still use the AppleScript to wrap it into a nice launchable app -- use this older hint to find the right command line commands.

Continued...

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Manpage of SCREEN
• Screen - s5h.net
• TIP Using screen - Gentoo Linux Wiki
• GNU Screen logging for the paranoid.

• Red Hat Magazine A guide to GNU Screen

• GNU Screen - Jonathan McPherson
• An Introduction to GNU Screen - DIT NetSoc
• screen - The Terminal Multiplexer
• Using GNU Screen
• An introduction to the visual features of GNU Screen
• Using GNU screen's multiuser feature for remote support
• z o r g . o r g - A Brief Introduction to Screen
• The Screen Program - Linux Forums
• An introduction to GNU screen - Network World
• http--www.networkworld.com-news-2006-100306-gnu-screen.html printable version
• A Guide to Efficiently Using Irssi and Screen f0rked.com
• eater.org-blog GNU Screen Hackery
• Yahoo GNU Screen Group A fairly high-traffic mailing list for screen. Many knowledgable people hang out here.
• Sven Guckes' Screen Page the latest version of Sven Guckes screen setup is available at http://www.guckes.net/Setup/screenrc [Jun 26, 2008]
• The official screen home page No explanation needed here. The page is surprising sparse on details.
• The screen man page Nicely formatted and separated by section. Good reference. Be sure to check out the sections on using .screenrc to customize screen.
• Screen FAQ Not for newbies, but a good resource to dig into for troubleshooting.

Solaris Packages

• screen-4.0.2-sol10-sparCtrl-local.gz Screen provides an ANSI/vt100 terminal emulator, which can multiplex up to 10 pseudo-terminals - installs in /usr/local. There are further configuration steps in the /usr/local/doc/screen/INSTALL. The etc and terminfo directories containing other relevant files are in /usr/local/doc/screen. The screen package may also require that you install the ncurses package.

Solaris Package Archive -- GNU screen 3.9.4

GNU screen 3.9.4 provides you with an ANSI/vt100 terminal emulator, which can multiplex up to 10 pseudo-terminals. On startup, it executes $SHELL in window 0. Then it reads $HOME/.screenrc to learn configuration, keybindings, and possibly open more windows. GNU screen has the ability to detach from your virtual screens and re-attach at a later time.

Email To
Send bug reports or queries to [email protected].

Upgrading Packages
When upgrading from an earlier GNU screen package, remember to pkgrm GNUscreen before you pkgadd the new version.

Solaris Issues
Click here to read about 32 bit and 64 bit packages.

Source Code
You can ftp the source code from ftp://ftp.gnu.org/pub/gnu/screen/screen-3.9.4.tar.gz

Special Issues
You may need to configure your terminal definitiosn to get the most out of GNU screen. See the files in the /usr/local/share/screen directory for more information.

See the main packages README for installation information.

User Manual

Screen User's Manual - Table of Contents

• 1 Overview

• 2 Getting Started

• 3 Invoking Screen

• 4 Customizing Screen

  • 4.1 The `.screenrc' file

  • 4.2 Colon

• 5 Commands

  • 5.1 Default Key Bindings

  • 5.2 Command Summary

• 6 New Window

  • 6.1 Chdir

  • 6.2 Screen Command

  • 6.3 Setenv

  • 6.4 Shell

  • 6.5 Term

  • 6.6 Window Types

• 7 Selecting a Window

  • 7.1 Moving Back and Forth

  • 7.2 Other Window

  • 7.3 Select

• 8 Session Management Commands

  • 8.1 Detach

  • 8.2 Power Detach

  • 8.3 Lock

  • 8.4 Multiuser Session

    • 8.4.1 Multiuser

    • 8.4.2 Acladd

    • 8.4.3 Aclchg

    • 8.4.4 Acldel

    • 8.4.5 Aclgrp

    • 8.4.6 Displays

    • 8.4.7 aclumask

    • 8.4.8 Wall

    • 8.4.9 Writelock

    • 8.4.10 Su

  • 8.5 Session Name

  • 8.6 Suspend

  • 8.7 Quit

• 9 Regions

  • 9.1 Split

  • 9.2 Focus

  • 9.3 Only

  • 9.4 Remove

  • 9.5 Caption

• 10 Window Settings

  • 10.1 Naming Windows (Titles)

    • 10.1.1 Title Command

    • 10.1.2 Dynamic Titles

    • 10.1.3 Setting up your prompt for shell titles

    • 10.1.4 Setting up shell titles in your `.screenrc'

  • 10.2 Console

  • 10.3 Kill

  • 10.4 Login

  • 10.5 Mode

  • 10.6 Monitoring

  • 10.7 Windows

  • 10.8 Hardstatus

• 11 Virtual Terminal

  • 11.1 Control Sequences

  • 11.2 Input Translation

  • 11.3 Digraph

  • 11.4 Bell

  • 11.5 Clear

  • 11.6 Info

  • 11.7 Redisplay

  • 11.8 Wrap

  • 11.9 Reset

  • 11.10 Window Size

  • 11.11 Character Processing

• 12 Copy and Paste

  • 12.1 Copying

    • 12.1.1 CR/LF

    • 12.1.2 Scrollback

    • 12.1.3 markkeys

    • 12.1.4 Movement Keys

    • 12.1.5 Marking

    • 12.1.6 Repeat Count

    • 12.1.7 Searching

    • 12.1.8 Specials

  • 12.2 Paste

  • 12.3 Registers

  • 12.4 Screen-Exchange

  • 12.5 History

• 13 Subprocess Execution

  • 13.1 Exec

  • 13.2 Using Exec

• 14 Key Binding

  • 14.1 The bind command

  • 14.2 Examples of the bind command

  • 14.3 Command Character

  • 14.4 Help

  • 14.5 Bindkey

  • 14.6 Bindkey Examples

  • 14.7 Bindkey Control

• 15 Flow Control

  • 15.1 About screen flow control settings

  • 15.2 Flow

  • 15.3 XON and XOFF

• 16 Termcap

  • 16.1 Choosing the termcap entry for a window

  • 16.2 Write out the window's termcap entry

  • 16.3 The termcap command

  • 16.4 Termcap Examples

  • 16.5 Special Terminal Capabilities

  • 16.6 Autonuke

  • 16.7 Obuflimit

  • 16.8 Character Translation

• 17 The Message Line

  • 17.1 Using the message line from your program

  • 17.2 Hardware Status Line

  • 17.3 Display Last Message

  • 17.4 Message Wait

• 18 Logging

  • 18.1 hardcopy

  • 18.2 log

• 19 Startup

  • 19.1 echo

  • 19.2 sleep

  • 19.3 Startup Message

• 20 Miscellaneous commands

  • 20.1 At

  • 20.2 Break

  • 20.3 Debug

  • 20.4 License

  • 20.5 Nethack

  • 20.6 Nonblock

  • 20.7 Number

  • 20.8 Silence

  • 20.9 Time

  • 20.10 Verbose

  • 20.11 Version

  • 20.12 Zombie

  • 20.13 Printcmd

  • 20.14 Sorendition

• 21 String Escapes

• 22 Environment Variables

• 23 Files Referenced

• 24 Credits

• 25 Bugs

  • 25.1 Known Bugs

  • 25.2 Reporting Bugs

  • 25.3 Availability

• 26 Installation

  • 26.1 Socket Directory

  • 26.2 Compiling Screen

• Concept Index

• Command Index

• Keystroke Index

Reference

• GNU Screen cheat-sheet - neophob
• FAQ
• quick_reference [GNU screen]
• Manpage of SCREEN

Manpage

[GNU screen manpage]

Each window in a screen session emulates a VT100 terminal, with some extra functions added. The VT100 emulator is hardcoded; no other terminal types can be emulated.

Usually screen tries to emulate as much of the VT100/ANSI standard as possible. But if your terminal lacks certain capabilities, the emulation may not be complete. In these cases screen has to tell the applications that some of the features are missing. This is no problem on machines using termcap, because screen can use the $TERMCAP variable to customize the standard screen termcap.

But if you do a rlogin on another machine or your machine supports only terminfo this method fails. Because of this, screen offers a way to deal with these cases. Here is how it works:

When screen tries to figure out a terminal name for itself, it first looks for an entry named "screen.<term>", where <term> is the contents of your $TERM variable. If no such entry exists, screen tries "screen" (or "screen-w" if the terminal is wide (132 cols or more)). If even this entry cannot be found, "vt100" is used as a substitute.

The idea is that if you have a terminal which doesn't support an important feature (e.g. delete char or clear to EOS) you can build a new termcap/terminfo entry for screen (named "screen.<dumbterm>") in which this capability has been disabled. If this entry is installed on your machines you are able to do a rlogin and still keep the correct termcap/terminfo entry. The terminal name is put in the $TERM variable of all new windows. Screen also sets the $TERMCAP variable reflecting the capabilities of the virtual terminal emulated. Notice that, however, on machines using the terminfo database this variable has no effect. Furthermore, the variable $WINDOW is set to the window number of each window.

The actual set of capabilities supported by the virtual terminal depends on the capabilities supported by the physical terminal. If, for instance, the physical terminal does not support underscore mode, screen does not put the us and ue capabilities into the window's $TERMCAP variable, accordingly. However, a minimum number of capabilities must be supported by a terminal in order to run screen; namely scrolling, clear screen, and direct cursor addressing (in addition, screen does not run on hardcopy terminals or on terminals that overstrike).

Also, you can customize the $TERMCAP value used by screen by using the "termcap" .screenrc command, or by defining the variable $SCREENCAP prior to startup. When the is latter defined, its value will be copied verbatim into each window's $TERMCAP variable. This can either be the full terminal definition, or a filename where the terminal "screen" (and/or "screen-w") is defined.

Note that screen honors the "terminfo" .screenrc command if the system uses the terminfo database rather than termcap.

When the boolean 'G0' capability is present in the termcap entry for the terminal on which screen has been called, the terminal emulation of screen supports multiple character sets. This allows an application to make use of, for instance, the VT100 graphics character set or national character sets. The following control functions from ISO 2022 are supported: lock shift G0 (SI), lock shift G1 (SO), lock shift G2, lock shift G3, single shift G2, and single shift G3. When a virtual terminal is created or reset, the ASCII character set is designated as G0 through G3. When the G0 capability is present, screen evaluates the capabilities S0, E0, and C0 if present. S0 is the sequence the terminal uses to enable and start the graphics character set rather than SI. E0 is the corresponding replacement for SO. C0 gives a character by character translation string that is used during semi-graphics mode. This string is built like the acsc terminfo capability.

When the po and pf capabilities are present in the terminal's termcap entry, applications running in a screen window can send output to the printer port of the terminal. This allows a user to have an application in one window sending output to a printer connected to the terminal, while all other windows are still active (the printer port is enabled and disabled again for each chunk of output). As a side-effect, programs running in different windows can send output to the printer simultaneously. Data sent to the printer is not displayed in the window. The info command displays a line starting 'PRIN' while the printer is active.

Screen maintains a hardstatus line for every window. If a window gets selected, the display's hardstatus will be updated to match the window's hardstatus line. If the display has no hardstatus the line will be displayed as a standard screen message. The hardstatus line can be changed with the ANSI Application Program Command (APC): ESC_<string>ESC\. As a convenience for xterm users the sequence ESC]0..2;<string>^G is also accepted.

Some capabilities are only put into the $TERMCAP variable of the virtual terminal if they can be efficiently implemented by the physical terminal. For instance, dl (delete line) is only put into the $TERMCAP variable if the terminal supports either delete line itself or scrolling regions. Note that this may provoke confusion, when the session is reattached on a different terminal, as the value of $TERMCAP cannot be modified by parent processes.

The "alternate screen" capability is not enabled by default. Set the altscreen .screenrc command to enable it.

The following is a list of control sequences recognized by screen. "(V)" and "(A)" indicate VT100-specific and ANSI- or ISO-specific functions, respectively.

Command line options

Screen has the following command-line options:

-a

include all capabilities (with some minor exceptions) in each window's termcap, even if screen must redraw parts of the display in order to implement a function.

-A

Adapt the sizes of all windows to the size of the current terminal. By default, screen tries to restore its old window sizes when attaching to resizable terminals (those with "WS" in its description, e.g. suncmd or some xterm).

-c file

override the default configuration file from "$HOME/.screenrc" to file.

-d|-D [pid.tty.host]

does not start screen, but detaches the elsewhere running screen session. It has the same effect as typing "Ctrl-a d" from screen's controlling terminal. -D is the equivalent to the power detach key. If no session can be detached, this option is ignored. In combination with the -r/-R option more powerful effects can be achieved:

-d -r

Reattach a session and if necessary detach it first.

-d -R

Reattach a session and if necessary detach or even create it first.

-d -RR

Reattach a session and if necessary detach or create it. Use the first session if more than one session is available.

-D -r

Reattach a session. If necessary detach and logout remotely first.

-D -R

Attach here and now. In detail this means: If a session is running, then reattach. If necessary detach and logout remotely first. If it was not running create it and notify the user. This is the author's favorite.

-D -RR

Attach here and now. Whatever that means, just do it.

Note: It is always a good idea to check the status of your sessions by means of "screen -list".

-e xy

specifies the command character to be x and the character generating a literal command character to y (when typed after the command character). The default is "Ctrl-a" and `a', which can be specified as "-e^Aa". When creating a screen session, this option sets the default command character. In a multiuser session all users added will start off with this command character. But when attaching to an already running session, this option changes only the command character of the attaching user. This option is equivalent to either the commands "defescape" or "escape" respectively.

-f, -fn, and -fa

turns flow-control on, off, or "automatic switching mode". This can also be defined through the "defflow" .screenrc command.

-h num

Specifies the history scrollback buffer to be num lines high.

-i

will cause the interrupt key (usually Ctrl-c) to interrupt the display immediately when flow-control is on. See the "defflow" .screenrc command for details. The use of this option is discouraged.

-l and -ln

turns login mode on or off (for /etc/utmp updating). This can also be defined through the "deflogin" .screenrc command.

-ls and -list

does not start screen, but prints a list of pid.tty.host strings identifying your screen sessions. Sessions marked `detached' can be resumed with "screen -r". Those marked `attached' are running and have a controlling terminal. If the session runs in multiuser mode, it is marked `multi'. Sessions marked as `unreachable' either live on a different host or are `dead'. An unreachable session is considered dead, when its name matches either the name of the local host, or the specified parameter, if any. See the -r flag for a description how to construct matches. Sessions marked as `dead' should be thoroughly checked and removed. Ask your system administrator if you are not sure. Remove sessions with the -wipe option.

-L

tells screen your auto-margin terminal has a writable last-position on the screen. This can also be set in your .screenrc by specifying `LP' in a "termcap" command.

-m

causes screen to ignore the $STY environment variable. With "screen -m" creation of a new session is enforced, regardless whether screen is called from within another screen session or not. This flag has a special meaning in connection with the `-d' option:

-d -m

Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts.

-D -m

This also starts screen in "detached" mode, but doesn't fork a new process. The command exits if the session terminates.

-O

selects a more optimal output mode for your terminal rather than true VT100 emulation (only affects auto-margin terminals without `LP'). This can also be set in your .screenrc by specifying `OP' in a "termcap" command.

-q

Suppress printing of error messages. In combination with "-ls" the exit value is as follows: 9 indicates a directory without sessions. 10 indicates a directory with running but not attachable sessions. 11 (or more) indicates 1 (or more) usable sessions. In combination with "-r" the exit value is as follows: 10 indicates that there is no session to resume. 12 (or more) indicates that there are 2 (or more) sessions to resume and you should specify which one to choose. In all other cases "-q" has no effect.

-r [pid.tty.host]

-r sessionowner/[pid.tty.host]

resumes a detached screen session. No other options (except combinations with -d/-D) may be specified, though an optional prefix of [pid.]tty.host may be needed to distinguish between multiple detached screen sessions. The second form is used to connect to another user's screen session which runs in multiuser mode. This indicates that screen should look for sessions in another user's directory. This requires setuid-root.

-R

attempts to resume the first detached screen session it finds. If successful, all other command-line options are ignored. If no detached session exists, starts a new session using the specified options, just as if -R had not been specified. The option is set by default if screen is run as a login-shell (actually screen uses "-xRR" in that case). For combinations with the -d/-D option see there.

-s

sets the default shell to the program specified, instead of the value in the environment variable $SHELL (or "/bin/sh" if not defined). This can also be defined through the "shell" .screenrc command.

-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. It substitutes the default [tty.host] suffix.

-t name

sets the title (a.k.a.) for the default shell or specified program. See also the "shelltitle" .screenrc command.

-U

Run screen in UTF-8 mode. This option tells screen that your terminal sends and understands UTF-8 encoded characters. It also sets the default encoding for new windows to `utf8'.

-v

Print version number.

-wipe [match]

does the same as "screen -ls", but removes destroyed sessions instead of marking them as `dead'. An unreachable session is considered dead, when its name matches either the name of the local host, or the explicitly given parameter, if any. See the -r flag for a description how to construct matches.

-x

Attach to a not detached screen session. (Multi display mode).

-X

Send the specified command to a running screen session. You can use the -d or -r option to tell screen to look only for attached or detached screen sessions. Note that this command doesn't work if the session is password protected.

Random Findings

dtach - A program that emulates the detach feature of screen

dtach is a tiny program that emulates the detach feature of screen, allowing you to run a program in an environment that is protected from the controlling terminal and attach to it later. dtach does not keep track of the contents of the screen, and thus works best with programs that know how to redraw themselves.

dtach does not, however, have the other features of screen, such as its support of multiple terminals or its terminal emulation support. This makes dtach extremely tiny compared to screen, making it more easily audited for bugs and security holes, and also allows it to fit in environments where space is limited, such as on rescue disks.

dtach has many possible uses, even though it is tiny. With dtach, you can:

• Attach multiple times to the same program. Access to the dtach session is controlled through the Unix filesystem permissions; thus, you can trivially allow other people to watch your session.
• Run a program in an environment that is protected from the controlling terminal. This means that, for instance, the program running under dtach would not be affected by the terminal being disconnected for some reason.
• Run programs such as emacs, which tend to want full control over the terminal. dtach mostly acts as a relay, and does not mangle the text between the application and your terminal.
• Suspend dtach without suspending the running program. dtach can handle the suspend key itself instead of passing it to the running program, which may be useful for certain programs such as ircII.

---

The latest version of dtach is version 0.7, which you can fetch here. Other download formats may be available at the sourceforge download area for dtach.

The changes in version 0.7 are:

• The redraw method can now be explicitly specified on the command line (either no redraw at all, the old ^L character method, and the new WINCH signal method), since many programs only handle one or the other properly.
• Changed the default redraw method back to the old ^L character method.
• Changed the attach code to check the return value of select more carefully.
• Changed the SIGWINCH handler to reinstall itself, to handle systems that always reset the handler.
• Added more proper process group handling.

The changes in version 0.6 are:

• Redraws are now handled by sending the child process a WINCH signal instead of by sending a ^L character. This should help prevent line-oriented programs (such as bash) from clearing the screen excessively.
• Flow control is now disabled when setting raw mode on the terminal.
• Switched to using select instead of poll.
• Changed some exits to exit succesfully instead of non-sucessfully.
• Updated my email address.
• Updated to Autoconf 2.59, renaming some files in the process.

The changes in version 0.5 are:

• Fix fd leakage.
• Prevent atexit from being called twice on dtach -A.

The changes in version 0.4 are:

• Slightly improved README and dtach.1
• Portability updates thanks to sourceforge's compile farm. dtach should now work on: FreeBSD, Debian/alpha, Debian/sparc, Debian/PPC, and Solaris.

The changes in version 0.3 are:

• Fixed a typo in dtach.1
• Changed the attach code so that it tells the master when a suspend occurs.
• Decreased the client <-> master packet size.
• Changed the master to send a stream of text to attaching clients instead of sending a huge packet all the time.
• Use getrlimit and dynamically allocate the data structures, if possible.
• Added some more autoconf checks.
• Initial sourceforge release.

You can also obtain information on how to access the CVS tree here, and access the sourceforge project page here.

You can send any comments or questions about dtach to the author. Comments and suggestions are welcome.

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

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: February 19, 2020