First off, it's recommended that you use screen
's scrollback buffer instead. Since you can have multiple windows in a screen
session, if you switch between those windows, your terminal scrollback will mix lines from all of those windows, but screen
keeps separate scrollback buffers for each one. Just use C-a ESC
or C-a [
to enter copy mode. (See also the interface examples for a description of how to make xterm
's keystrokes work on screen
instead.) But if you do want scrollback in your terminal window (usually xterm
), read on.
Some background: One capability that a terminal may have is an “alternate screen”. xterm
has it, and you may have seen its effects–a program will request the alternate screen, the terminal switches there, and when the program exits the terminal goes back to the normal screen, leaving all the text there intact. It is recommended that all full-screen apps use this, so as to minimize their impact on any purely command-line stuff. It makes sense, for instance, for vi
to use the alternate screen. The drawback to the alternate screen is that only the main screen accumulates scrollback.
As you might have guessed, screen
uses the alternate screen, if it's available. There's no real way to turn off use of the alternate screen, but you can make screen
think that the terminal doesn't have an alternate screen with the termcapinfo
command:
termcapinfo xterm* ti@:te@
In your .screenrc:
termcapinfo xterm*|rxvt*|kterm*|Eterm* 'hs:ts=\E]0;:fs=\007:ds=\E]0;\007' defhstatus "screen ^E (^Et) | $USER@^EH" hardstatus off
Some terminals have a “hardstatus” line–a region that is separate from the main block of text but that programs can use to show status messages. The termcap entry hs
indicates that a terminal has a hardstatus line. ts
gives the escape sequence for entering the hardstatus line, fs
gives the escape sequence for leaving it, and ds
gives the escape sequence for clearing it. The above hack treats xterm
's titlebar as a hardstatus line and defines a default status string. (The status string understands the normal string escapes, but uses '^E' in place of '%'.) The hardstatus off
line tells screen not to print status messages (such as “Bell in window 0” and so on) via the hardstatus line, useful since it isn't a real hardstatus line.
As mentioned in the virtual terminal, programs in screen
can use the escape sequence ESC_<message>ESC\
to change the hardstatus message for a particular window. The sequence ESC]0;<message>^G
also works, so with the above hardstatus hack in place, programs' changes to the xterm
titlebar will be passed through screen
.
See the status bar and xterm title example for more details.
See the page on title examples.
See the page on sessionnames.
(The implied question being, “How do I keep my split windows over a detach?”)
The short is answer is that you can't. The longer answer is that you can fake it. (Note: the next screen
release, probably numbered 4.1.0, will be able to remember display layouts.)
Splits are a property of your display. The process managing your screen
session doesn't really know about them; only the single process that's displaying the session does. Thus, the screen
session can't remember the splits because it doesn't know about them, and once you detach, the process that did know about them has exited.
The hack is to use nested screen
sessions. Start one session and give it some escape sequence that you won't use much (or just disable its escape character completely). Bind your usual detach key sequence to this screen
session. Now, start or attach to your main screen
session. All of your work will be done in the inner session, and you can split your display. When you detach, however, it will be the outer session that detaches, so your splits in the inner session will be preserved.
Assuming you use the default escape character, C-a, your alternate screenrc should contain:
escape "" bindkey ^ad detach
(We assume that we have a screen
session with the name “test” running with a window 0.)
screen -S test -p 0 -X stuff 'top^M'
The '^M' needs to be literal so precede it with '^V' in bash, for example. Or you can use the (four characters) '\012' (which works for bash only in a script).
One can launch a program in a new window easily by simply typing the following at a commandline:
screen top
The window will appear with the application (in this case, top
) running. The following will open it, and switch back to your current window, in effect “launching” the command in the background:
screen -X eval 'screen top' 'other'
Example: You want to run HellaNZB and HellaHella at the same time, in one session, with useful window names. Create a custom screenrc (e.g. $HOME/.screenrc_hellanzb):
hella_ini=/mnt/usenet/nzbs/hella.ini cat > ~/.screenrc_hellanzb <<_EOF sessionname hellanzb screen -t hellanzb hellanzb.py screen -t hellahella paster serve $hella_ini _EOF
Now you can run screen.
screen -dm -c ~/.screenrc_hellanzb
Reattaching is easy.
screen -r hellanzb
You can patch gnome-terminal to become screen
-aware, after which screen
windows appear as tabs in the terminal, and you can still attach and detach from the screen
session.
Deleted tutorial via wayback machine :https://web.archive.org/web/20100505231752/http://monia.wordpress.com:80/2006/08/31/integrating-gnome-terminal-and-screen/
When your outer/local screen
session appears to catch your escape character, you have two options to send the escape to the inner screen
session:
C-a
to the inner session, with C-a a
. For example, if you want to send C-a c
to the inner session, you would type C-a a c
to the outer session. For deeper nesting, just add more (middle) a
keystrokes for each nested level.
On Linux, we've heard that reptyr will let you pull a process into screen
(i.e. grab its controlling terminal). reptyr
claims to be better than screenify
.