| |
| 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:
ftp.uni-erlangen.de:/pub/utilities/screen/private/color_xterm_patch
|
| |
| 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:%.)%# "
else
set prompt="%h (%m:%.)%# "
endif
|
(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 |
lqqqwk
x a xx
tqqqnu
mqqqvj
|
+---++
| : ||
+---++
+---++
|
)0lqqqwk
x a xx
tqqqnu
mqqqvj)B
|
|
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
http://www.ccil.org/~esr/terminfo
, which is maintained by
Eric S. Raymond <esr@snark.thyrsus.com>. 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
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
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
Previous versions of screen can switch off the status messages with the
standard xterm title sequence issued from an echo command in a shell:
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:
and waits (according to ansi) for the string terminator
Screen versions after 3.5.12 may provide a workaround.
|
| |
| 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
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
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:
|
| |
| 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
ftp.uni-erlangen.de:/pub/utilities/screen/sed-2.02b.tar.gz
|
| |
| 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.
tromey@klab.caltech.edu (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):
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'
|
|
| |
| 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
(pkn@cs.utexas.edu) 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:
|