Screen FAQ

jw, Wed Nov 17 22:06:46 MET 1999
This is a list of frequently asked questions on



Terminal woes

<< >>
Q: Color is ignored when inside screen. Without screen it works!
A: Your terminals termcap/terminfo entry does not advertise color support properly. Screen version 3.7.6 does automatic color support guessing. Please upgrade. (If you have this problem with 3.7.6, you found a bug!) For older screen versions you can either patch the database or add tweaks to the (preferrably global) screenrc file. The tweaks for the color xterm would be:
termcap  xterm 'AF=\E[3%dm:AB=\E[4%dm'
terminfo xterm 'AF=\E[3%p1%dm:AB=\E[4%p1%dm'
add these two lines to your ~/.screenrc file. Here is, what these codes mean:
AF (setaf) = Set foreground color (ANSI compatible)
AB (setab) = Set background color (ANSI compatible)
AX         = Does have ANSI set default fg/bg color (\E[39m / \E[49m)
Note that the linux color xterm has a stupid bug: the characters get the color of the cursor, therefore if you change color and move the cursor around all the characters will get the new color... rxvt works just fine. Here is a patch for xterm:
Q: My xterm scrollbar does not work with screen.
A: The problem is that xterm will not allow scrolling if the alternate text buffer is selected. The standard definitions of the termcap initialize capabilities ti and te switch to and from the alternate text buffer. (The scrollbar also does not work when you start e.g. 'vi'). You can tell screen not to use these initialisations by adding the line
termcapinfo xterm ti@:te@
to your ~/.screenrc file.
Q: The cursor left key deletes the characters instead of just moving the cursor. A redisplay (^Al) brings everything back.
A: Your terminal emulator (probably xterm) treats the backspace as "destructive". You can probably change this somewhere in the setup. We can't think of a reason why anybody would want a destructive backspace, but if you really must have it, add the line
termcapinfo xterm 'bc@:bs@'
to your ~/.screenrc (replace xterm with the terminal type of your emulator, if different).
Q: I have a 7-bit terminal that can show german umlaut characters (a-dieresis, etc..) by switching mode pages. Can screen do the trick?
A: Many modern applications assume that an 8-bit character set is available that conforms to iso-latin1. Screen can convert such output to drive old 7-bit terminals. You need to describe your terminals' features with the XC termcap capability. See the manual section about Character Translation for details.
Q: 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:%.)%# "
	set prompt="%h (%m:%.)%# "
(Note that ESC means a real ESC (otcal 033) chars).
Q: I can't get character line graphics (from the alternate character set) under screen.
A: Check if your system has installed an up-to-date termcap/terminfo entry for screen.
Here is a block of character line art displayed in four versions. The 3rd uses ANSI codes. 7-bit chars minus/plus/pipe graphics font HTML table
x a xx
| : ||
x a xx     
Another version of the above table is hidden as a comment in the page soure of this document. Cut that from the document and save it to a file. Then cat the file to the terminal from within screen.
If the block labelled `graphics font' looks like the `HTML-table' block, everything is all right.
If you get `only 7-bit characters' (like in the first block), then screen's termcap/terminfo description is incorrect, or your application does not follow this entry and produces wrong codes.

The termcap entry needs to contain
:as=^N:ae=^O:aE=\E(B\E)0:ac=``aaffggjjkkllmmnnooppqqrr ssttuuvvwwxxyyzz{{||}}~~..--++  ,,hhII00:
(as a single line) and the terminfo entry needs to contain
smacs=^N, rmacs=^O, enacs=\E(B\E)0, acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~ ~..--++\054\054hhII00,
with line breaks only after commas.

If you see crude `minus/plus/pipe graphics' (like in the second block), screen's own entry is correct (at least your application sent codes that screen understood). But screen believes that the physical terminal could not display real ANSI line graphics, which would requires the use of the alternate character set. Possibly the termcap/ terminfo entry (for your actual terminal!) does not indicate that the terminal has one.

Screen versions up to 3.6.2 would only dare to use the alternate charset on terminals having the boolean capability :G0: in their termcap entry. On terminfo based systems :G0: could only be presented with the command `terminfo' in a .screenrc file.

Q: Screen gets the terminal size wrong and messes up.
A: Before you start screen: Check with 'stty -a' what the terminal driver thinks about rows and columns. Check the environment variables LINES and COLUMNS. Then from within screen check with the info command (CTRL-A i) what size screen thinks your terminal is. If correcting tty driver setting and environment variables does not help, look up the terminal capability definition. First the TERMCAP environment variable. If this is not set, look up the terminals name as defined in the environment variable TERM in /etc/termcap or in the terminfo database with untic or infocmp. There may be :li=...: and :co=...: or even :ll=...: entries (cols#... and lines#... when it's terminfo) defined incorrectly. Either construct your own TERMCAP environment variables with correct settings, use screens terminfo/termcap command in your .screenrc file or have the database corrected by the system administrator.
Q: Screen messes up the terminal output when I use my favourite application. Setting the terminal size does not help.
A: Probably you got some termcap/terminfo entries wrong. Fixing this is a three stage procedure.

First, find out if terminfo or termcap is used. If your system only has /etc/termcap, but not /usr/lib/terminfo/... then you are using termcap. Easy. But if your system has both, then it depends how the application and how screen were linked. Beware, if your application runs on another host via rlogin, telnet or the like, you should check the terminfo/termcap databases there. If you cannot tell if terminfo or termcap is used (or you just want to be save), the do all steps in stage 3 in parallel for both systems (on all envolved hosts).

Second: Understand the basic rules how screen does its terminal emulation. When screen is started or reattached, it relies on the TERM environment variable to correctly reflect the terminal type you have physically in front of you. And the entry should either exist in the system terminfo/termcap database or be specified via the TERMCAP environment variable (if screen is using the termcap system). On the other end, screen understands one set of control codes. It relies on the application using these codes. This means applications that run under screen must be able to adapt their control codes to screen. The application should use the TERM variable and termcap or terminfo library to find out how to drive its terminal. When running under screen, the terminal is virtual and is only defined by the set of control codes that screen understands. The TERM variable is automatically set to "screen" and the "screen"-entries should exist in the databases. If your application uses hardcoded control codes rather than a database, you are on your own. Hint: The codes understood by screen are a superset of the very common definition named "vt100". Look at the documentation of screen. The codes are listed there.

Third: Have the entry "screen" installed on all hosts or make sure you can live with "vt100". Check the codes sent by your application, when the TERM variable is set to "screen". Do not try to set the TERM variable inside screen to anything other than "screen" or "vt100" or a known compatible. Thus your application can drive screen correctly. Also take care that a good entry is installed for your physical terminal that screen has to drive (Many systems come with broken entries, even for xterm). screen is very picky and even if the entry was good enough for your application to drive the terminal directly, screen may find flaws, as it tries to do speed optimizing. The screenrc commands "termcapinfo", termcap" and/or "terminfo" may help to fine-tune capabilities without calling the supervisor to change the database.

Q: I am using screen with a YYY terminal, which supports the XXX graphic language. I am very happy with it, except one thing: I cannot render graphics into screen windows.
A: You are out of luck there. Screen provides a fixed set of escape sequences in order to make it possible to switch terminal types. Screen has to know exactly what the escape sequences do to the terminal because it must hold an image in memory. Otherwise screen could not restore the image if you switch to another window. Because of this you have to change screens escape sequence parser (ansi.c) to pass the XXX graphics sequences to the terminal. Of course the graphics will be lost if you switch to another window. Screen will only honour graphics sequences that are demanded by an overwhelming majority.
Q: Screen does not work correctly on my special XXX terminal, as I cannot find a proper termcap entry for the terminal.
A: Termcap entries for the most exotic terminals can be found at , which is maintained by Eric S. Raymond <>. If your system has both terminfo and termcap, applications may find a correct entry in one database, screen may not find (or find a bad one) in the other database, please verify that both are in sync.
Q: Sometimes when I select the window number 4, the screen session dies.
A: Yes, window 4 is more dangerous than other windows. This is a "feature" of all vt100 style keyboards. You accidently typed CTRL-A CTRL-4 instead of CTRL-A 4 to select the window. CTRL-4 happens to be the same keycode as CTRL-\ on vt100-keyboards and CTRL-A CTRL-\ is bound to the 'quit' command per default. Add the line
bind '^\'
to your ~/.screenrc file, as also suggested in the etcscreenrc that comes with the distribution.
Q: The backspace key no longer works in version 3.9.5
A: Screen 3.7.4 used to map the backspace key (see term.c) but this caused too much trouble with some *BSD distributions, which had kb=^? in their termcap entries.

In fact, the kb capability doesn't make much sense as it is ignored by all programs I know. They use the terminal driver setting (see 'stty') instead. So it breaks the programs if screen maps ^? to ^h.

If you really need the old mapping, add
bindkey -d kb stuff ^H
to your ~/.screenrc file. This is equivalent to the removed mapping in term.c.

Q: The window list (C-a w) overlays onto the bottom line of screen and disappears after a few seconds. Can I use one line less for my applications and have this line permanent?
A: Screen 3.9.x offers the 'alwayslastline' option to the hardstatus command. For a permanent display of the window list, use '%w'. The following command may go into your ~/.screenrc file:
hardstatus alwayslastline "%w"
Q: When switching between windows, some stupid information is printed into the bottom line of screen and vanishes after a few seconds. How do I stop that?
A: Screen 3.9.x offers the 'hstatus' command, to control where status messages go. To switch them off (for the current window), use
hstatus ""
Previous versions of screen can switch off the status messages with the standard xterm title sequence issued from an echo command in a shell:
ESC ] 0 ; ^G
The cause of this problem is, that your .profile (or .cshrc) contains settings to display some status information in the titlebar of your xterm. This is done even if the terminal is screen rather than xterm. If you find out, where the SuSE 6.1 Linux installation is hiding this code, please tell us.
Q: When I type cd directory (any directory or just blank) from within one of the windows in screen, the whole thing just freezes up.
A: You display the current working directory in xterm's title bar, This may be caused by hardcoded ESC-sequences in the shell prompt or in an cd alias. In Xterm the coding is
ESC ] n ; string_to_display ^G
where n = 1, 2, 3 selects the location of the displayed string. Screen misinterprets this as the ansi operating system comment sequence:
ESC ] osc_string
and waits (according to ansi) for the string terminator
Screen versions after 3.5.12 may provide a workaround.

General woes

<< >>
Q: Is screen year 2000 compliant?
A: As far as we know screen has no Y2K problem, but as the GPL says, even if there is a problem, WE ARE NOT LIABLE and THERE IS NO WARRANTY.

See also the y2k-article that Tom Christiansen wrote for perl5. Much of it applies to screen as well.

Q: My aliases do not work in screen. Ho do I make it so that everytime I open a new screen, it sources my .bash_login (or csh's .login, etc.) file?
A: Add the line
shell -$SHELL
to your ~/.screenrc file. this makes the shells think that they are login shells and have to do full initialisation. For csh-like shells this means, that both .login and .cshrc files will be loaded. Ususally people are satisfied when shells under screen only sources their .cshrc file.
Q: How can I set screen to have shell tcsh for every new window?
A: RTFM. You'll find a total of three different ways in the manual:

1). Put the line
shell tcsh
in your ~/.screenrc file.

2). Start screen with the option -s tcsh

3). Set the environment variable $SHELL to the value 'tcsh'.
All these rely on having tcsh in your search path. If not, just specify the complete path instead of the word 'tcsh'.

Q: Mesg or biff cannot be turned on or off while running screen.
A: Screen failed to change the owner of the pty it uses. You need to install screen setuid-root. See the file INSTALL for details.
Q: Why is it impossible to download a file with Kermit/sz/rz when screen is running? Do I need to set some special variables?
A: Screen always interprets control-sequences sent by the applications and translates/optimizes them for the current terminal type. Screen always parses the user input for its escape character (CTRL-A). Both are basic screen features and cannot be switched off. Even if it were possible to switch screen into a completely transparent mode, you could never switch between windows, while kermit/sz/rz is downloading a file. You must wait til the end as kermit/sz/rz will not transmit your input during a file transfer and as kermit/sz/rz would be very confused if screen switched away the window containing the other kermit/sz/rz. Simply detach your screen session for each file transfer and start the transfer program only from the shell where you started screen.
Q: If I leave screen too long detached it mysteriously disappears, although I feel that this is not a flaw in the program but rather my system being 'cleaned' of stray jobs.
A: Check the output of "screen -ls". If there is no session, your shells inside screen possibly have set an autologout. This kills the processes after a certain time of inactivity. Such a feature is often installed per default in the users account, as it helps to keep intruders off on terminals where you forgot to log out. But it is not a good idea for shells running under screen.

If your session shows up in "screen -ls", your shells are o.k. and screen is still running. Possibly you cannot re-attach your session, because the directory containing your screen socket (e.g. /tmp/) has been cleared. Then see the entry below.

Q: For some unknown reason, the fifo in /tmp/screens/S-myname is gone, and i can't resume my screen session. Is there a way to recreate the fifo?
A: Screen checks the fifo/socket whenever it receives a SIGCHLD signal. If missing, the fifo/socket is recreated then. If screen is running non set-uid the user can issue a 'kill -CHLD screenpid' directly (it is -CHILD on some systems). Screenpid is the process-id of the screen process found in a 'ps -x' listing. But usually this won't work, as screen should be installed setuid root. In this case you will not be able to send it a signal, but the kernel will. It does so, whenever a child of screen changes its state. Find the process-id (shellpid below) of the "least important" shell running inside screen. The try 'kill -STOP shellpid'. If the fifo/socket does not reappear, destroy the shell process. You sacrify one shell to save the rest. If nothing works, please do not forget to remove all processes running in the lost screen session.
Q: When you start screen a page of text comes up to start you off. Is there a way to get rid of this text?
A: Just put the following line in your ~/.screenrc file:
startup_message off
Q: I cannot configure screen. Sed does not work.
A: The regular expressions used in our configure scrip are too complicated for GNU sed version 2.03. In this regard it is bug compatible with Ultrix 3.1 "sed": GNU sed version 2.03 dumps core with our configure script. Try an older release. E.g. from
Q: Start "screen emacs" and run emacs function suspend-emacs (ctrl-z). The window containing emacs vanishes.
A: This is a known bug. Unfortunatly there is no easy fix because this is specified in the POSIX standard. When a new window is created Screen opens up a new session because the window has to get the pty as a controlling terminal (a session can only have one controlling terminal). With the setsid() call the process also creates a new process group. This process group is orphaned, because there is no process in the session which is not in the process group. Now if the process group leader (i.e. your program) gets a TTIN/TTOU/TSTP, POSIX states that the kernel must send a KILL signal to the process group because there is no one left to continue the process. Even if screen would try to restart the program, that would be after it received the KILL signal which cannot be caught or ignored. (Tom Tromey): I've noticed this exact same problem. I put this in my .emacs file. It seems to work:
;; If running under screen, disable C-z.
(if (and (getenv "STY") (not window-system))
     (global-unset-key "\C-z"))

Q: When reattaching a session from a different Workstation, I cannot connect the X-Server. Even ``CTLR-A : setenv DISPLAY newhost:0'' does not work as expected.
A: Under unix every process has its own environment. The environ- ment of the SCREEN process can be changed with the `setenv' com- mand you tried above. This however cannot affect the environment of the shells or applications already running under screen. Only subsequently spawned processes will reflect the changes. One should be aware of this problem when running applications from very old shells. You need to update the DISPLAY environment variables in every shell manually. Otherwise they point at the wrong X-Server.
Q: The "talk" command does not work when Screen is active.
A: Talk and several other programs rely on entries in the Utmp-Database (/etc/utmp). On some systems this Database is world writable, on others it is not. If it is not, screen must be installed with the appropriate permissions (user or group s-bit) just like any program that uses PTYs (rlogin, xterm, ...). When screen cannot write to utmp, you will see messages on your display about that problem - this also indicates that talk will run into trouble.

When screen can update utmp, it is not guaranteed that it does as you expect. First this depends on the config.h file defining UTMPOK, LOGINDEFAULT, and perhaps CAREFULUTMP. Second it depends on the screenrc files (system wide and per user), if utmp entries are done. Third, you can control whether windows are logged in with screens ``login'' command.

Q: The 'logdir' command no longer works. Why this?
A: It has been replaced in version 3.7.0 by the more powerful 'logfile' command. Now you specify the full path and filename of the logfiles, where the following translations apply:
        %t - title
        %n - number (a single % still works)
        %d - day
        %D - weekday name
        %m - month
        %M - month name
        %y - year (2 digit)
        %Y - year (4 digit)
        %w - hour:minutes (24h format)
        %W - hour:minutes (12h format)
        %s - seconds
        %a - am/pm
        %A - AM/PM
Btw, these translations also apply to activity, bell messages, window title strings, etc. Please do not use a single '%' character for window titles any more. It is obsoleted by '%n' and will vanish in future releases.
Q: In zombie-mode, screen says, I shall input ^@ to resurrect the window. How do I do that?
A: The '^' means "press the Ctrl key". Ctrl-@ is supposed to produce a hex 0x00 character code. If the '@'-Character is Shift-2 or Alt-Q or another combination, then there is no such thing as Ctrl-@. Try Ctrl-Space, this may produce the 0x00 character code. Ctrl-2, Ctrl-Shift-2, etc... may also work. See also the usage of "stuff" and the abuse of "exec" below.
Q: How do I 'type' a special character code that I cannot produce with my keyboard?
A: Calculate the octal digit representation of your code then use screens builtin the stuff command. This example will insert the default command character (Just like Ctrl-A a does):
Ctrl-A :stuff "\001"
All codes between \001 and \0377 can be produced this way. The code \000 leads to an error message, due to a limitation of the input parser. You can use a construct similar to the following (e.g. for resurrecting zombies)
Ctrl-A :exec !! sh -c 'echo | tr \\012 \\000'

Compiler woes

<< >>
Q: display.o(.text+0xafe): undefined reference to `xtputs'
A: Yes, we somehow assumed that all linux distributions use the curses library. Here is a fix (required up to screen-3.7.6):
--- os.h.orig   Sun Dec 20 16:39:50 1998
+++ os.h        Sun Dec 20 16:40:21 1998
@@ -210,7 +210,7 @@
 /* linux ncurses is broken, we have to use our own tputs */
-#ifdef linux
+#if defined(linux) && defined(TERMINFO)
 # define tputs xtputs
Q: Screen-3.7.6 does not compile under SCO OpenServer Release 5.0.2:
/usr/include/sys/resource.h:51: field `ru_utime' has incomplete type
A: Jim.Greer@AUTOZONE.COM suggests to add the following before the include of <sys/resource.h> in screen.c at line 51:
#if defined(SVR4)
# include 

Operating system woes

<< >>
Q: Screen compiles fine but when you try to start it you get:
InitPty: cannot I_PUSH ptem: Invalid argument
A: This is a change in Linux that caught us by surprise, this problem is fixed in version 3.9.5
Q: Some programs dump core when run under screen, some don't.
A: Screen likes to set the environment variable $TERMCAP to a string longer than 1024 characters. Some programs use a buffer of 1024 characters when they call the tgetent() library function. You'll need to recompile these programs with a bigger buffer. I'd recommend at least 2048 characters.
Q: About once every 5 times I ran the program, rather than getting a "screen," I got someone elses IRC output/input.
A: This Problem is due to a known bug in SunOS 4.1.x. What happened is that an IRC process was left running on a pseudo tty in such a way that the kernel thought the tty was available for reallocation. You can fix this behaviour by applying the SunOS 4.1.x tty jumbo patch (100513-04).
Q: Screen compiled on SunOS 5.3 cannot reattach a detached session.
A: You are using /usr/ucb/cc, this compiler is wrong. Actually it links with a C-library that mis-interprets dirent. Try again with /opt/SUNWspro/bin/cc!
Q: Seteuid() does not work as expected in AIX. Attempting a multi- user-attach results in a screen-panic: "seteuid: not owner".
A: This is not a screen problem. According to Kay Nettle ( you need the AIX patch PTF 423674.
Q: I have an old SysV OS (like Motorola SysV68) and sometimes screen does not reset the attributes correctly. Even a redisplay (^Al) does not help.
A: The libcurses library has a bug if attributes are cleared with the special ue/se capabilities. As a workaround (other than upgrading your system) modify 'rmul' (and 'rmso'?) in screen's terminfo entry:
rmul=\E[m, rmso=\E[m