Go to the first, previous, next, last section, table of contents.


screen demands the most out of your terminal so that it can perform its VT100 emulation most efficiently. These functions provide means for tweaking the termcap entries for both your physical terminal and the one simulated by screen.

Choosing the termcap entry for a window

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

Also, you can customize the $TERMCAP value used by screen by using the termcap command, or by defining the variable $SCREENCAP prior to startup. When the 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 command if the system uses the terminfo database rather than termcap. On such machines the $TERMCAP variable has no effect and you must use the dumptermcap command (see section Write out the window's termcap entry) and the tic program to generate terminfo entries for screen windows.

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.

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. You can force screen to include all capabilities in $TERMCAP with the `-a' command-line option (see section Invoking Screen).

Write out the window's termcap entry

Command: dumptermcap
(C-a .)
Write the termcap entry for the virtual terminal optimized for the currently active window to the file `.termcap' in the user's `$HOME/.screen' directory (or wherever screen stores its sockets. see section Files Referenced). This termcap entry is identical to the value of the environment variable $TERMCAP that is set up by screen for each window. For terminfo based systems you will need to run a converter like captoinfo and then compile the entry with tic.

The termcap command

Command: termcap term terminal-tweaks [window-tweaks]
Command: terminfo term terminal-tweaks [window-tweaks]
Command: termcapinfo term terminal-tweaks [window-tweaks]
Use this command to modify your terminal's termcap entry without going through all the hassles involved in creating a custom termcap entry. Plus, you can optionally customize the termcap generated for the windows. You have to place these commands in one of the screenrc starup files, as they are meaningless once the terminal emulator is booted.

If your system uses the terminfo database rather than termcap, screen will understand the terminfo command which has the same effects as the termcap command. Two separate commands are provided, as there are subtle syntactic differences, e.g. when parameter interpolation (using `%') is required. Note that the termcap names of the capabilities have to be used with the terminfo command.

In many cases, where the arguments are valid in both terminfo and termcap syntax, you can use the command termcapinfo, which is just a shorthand for a pair of termcap and terminfo commands with identical arguments.

The first argument specifies which terminal(s) should be affected by this definition. You can specify multiple terminal names by separating them with `|'s. Use `*' to match all terminals and `vt*' to match all terminals that begin with `vt'.

Each tweak argument contains one or more termcap defines (separated by `:'s) to be inserted at the start of the appropriate termcap entry, enhancing it or overriding existing values. The first tweak modifies your terminal's termcap, and contains definitions that your terminal uses to perform certain functions. Specify a null string to leave this unchanged (e.g. ""). The second (optional) tweak modifies all the window termcaps, and should contain definitions that screen understands (see section Virtual Terminal).

Termcap Examples

Some examples:

termcap xterm*  xn:hs@

Informs screen that all terminals that begin with `xterm' have firm auto-margins that allow the last position on the screen to be updated (xn), but they don't really have a status line (no 'hs' -- append `@' to turn entries off). Note that we assume `xn' for all terminal names that start with `vt', but only if you don't specify a termcap command for that terminal.

termcap vt*  xn
termcap vt102|vt220  Z0=\E[?3h:Z1=\E[?3l

Specifies the firm-margined `xn' capability for all terminals that begin with `vt', and the second line will also add the escape-sequences to switch into (Z0) and back out of (Z1) 132-character-per-line mode if this is a VT102 or VT220. (You must specify Z0 and Z1 in your termcap to use the width-changing commands.)

termcap vt100  ""  l0=PF1:l1=PF2:l2=PF3:l3=PF4

This leaves your vt100 termcap alone and adds the function key labels to each window's termcap entry.

termcap h19|z19  am@:im=\E@:ei=\EO  dc=\E[P

Takes a h19 or z19 termcap and turns off auto-margins (am@) and enables the insert mode (im) and end-insert (ei) capabilities (the `@' in the `im' string is after the `=', so it is part of the string). Having the `im' and `ei' definitions put into your terminal's termcap will cause screen to automatically advertise the character-insert capability in each window's termcap. Each window will also get the delete-character capability (dc) added to its termcap, which screen will translate into a line-update for the terminal (we're pretending it doesn't support character deletion).

If you would like to fully specify each window's termcap entry, you should instead set the $SCREENCAP variable prior to running screen. See section Virtual Terminal, for the details of the screen terminal emulation. See section `Termcap' in The Termcap Manual, for more information on termcap definitions.

Special Terminal Capabilities

The following table describes all terminal capabilities that are recognized by screen and are not in the termcap manual (see section `Termcap' in The Termcap Manual). You can place these capabilities in your termcap entries (in `/etc/termcap') or use them with the commands termcap, terminfo and termcapinfo in your screenrc files. It is often not possible to place these capabilities in the terminfo database.

Terminal has VT100 style margins (`magic margins'). Note that this capability is obsolete -- screen now uses the standard `xn' instead.
Change width to 132 columns.
Change width to 80 columns.
Resize display. This capability has the desired width and height as arguments. SunView(tm) example: `\E[8;%d;%dt'.
Terminal doesn't need flow control. Send ^S and ^Q direct to the application. Same as flow off. The opposite of this capability is `nx'.
Terminal can deal with ISO 2022 font selection sequences.
Switch charset `G0' to the specified charset. Default is `\E(%.'.
Switch charset `G0' back to standard charset. Default is `\E(B'.
Use the string as a conversion table for font 0. See the `ac' capability for more details.
Switch cursor keys to application mode.
Switch cursor keys to cursor mode.
Enable autonuke for displays of this terminal type. (see section Autonuke).
Set the output buffer limit. See the `obuflimit' command (see section Obuflimit) for more details.
Set the kanji type of the terminal. Valid strings are `jis', `euc' and `sjis'.
Change character forground color in an ANSI conform way. This capability will almost always be set to `\E[3%dm' (`\E[3%p1%dm' on terminfo machines).
Same as `AF', but change background color.
Does understand ANSI set default fg/bg color (`\E[39m / \E[49m').
Describe a translation of characters to strings depending on the current font. (see section Character Translation).


Command: autonuke state
Sets whether a clear screen sequence should nuke all the output that has not been written to the terminal. See section Obuflimit. This property is set per display, not per window.

Command: defautonuke state
Same as the autonuke command except that the default setting for new displays is also changed. Initial setting is off. Note that you can use the special AN terminal capability if you want to have a terminal type dependent setting.


Command: obuflimit [limit]
If the output buffer contains more bytes than the specified limit, no more data will be read from the windows. The default value is 256. If you have a fast display (like xterm), you can set it to some higher value. If no argument is specified, the current setting is displayed. This property is set per display, not per window.

Command: defobuflimit limit
Same as the obuflimit command except that the default setting for new displays is also changed. Initial setting is 256 bytes. Note that you can use the special OL terminal capability if you want to have a terminal type dependent limit.

Character Translation

Screen has a powerful mechanism to translate characters to arbitrary strings depending on the current font and terminal type. Use this feature if you want to work with a common standard character set (say ISO8851-latin1) even on terminals that scatter the more unusual characters over several national language font pages.


    <charset-mapping> := <designator><template>{,<mapping>}
    <mapping> := <char-to-be-mapped><template-arg>

The things in braces may be repeated any number of times.

A <charset-mapping> tells screen how to map characters in font <designator> (`B': Ascii, `A': UK, `K': german, etc.) to strings. Every <mapping> describes to what string a single character will be translated. A template mechanism is used, as most of the time the codes have a lot in common (for example strings to switch to and from another charset). Each occurence of `%' in <template> gets substituted with the template-arg specified together with the character. If your strings are not similar at all, then use `%' as a template and place the full string in <template-arg>. A quoting mechanism was added to make it possible to use a real `%'. The `\' character quotes the special characters `\', `%', and `,'.

Here is an example:

    termcap hp700 'XC=B\E(K%\E(B,\304[,\326\\\\,\334]'

This tells screen, how to translate ISOlatin1 (charset `B') upper case umlaut characters on a hp700 terminal that has a german charset. `\304' gets translated to `\E(K[\E(B' and so on. Note that this line gets parsed *three* times before the internal lookup table is built, therefore a lot of quoting is needed to create a single `\'.

Another extension was added to allow more emulation: If a mapping translates the unquoted `%' char, it will be sent to the terminal whenever screen switches to the corresponding <designator>. In this special case the template is assumed to be just `%' because the charset switch sequence and the character mappings normaly haven't much in common.

This example shows one use of the extension:

    termcap xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334'

Here, a part of the german (`K') charset is emulated on an xterm. If screen has to change to the `K' charset, `\E(B' will be sent to the terminal, i.e. the ASCII charset is used instead. The template is just `%', so the mapping is straightforward: `[' to `\304', `\' to `\326', and `]' to `\334'.

Go to the first, previous, next, last section, table of contents.