vi:set wm=5 jw 21.10.93 20.11.95 27.03.96 screen: frequently asked questions -- known problems -- unimplemented bugs =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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: Color is ignored when inside screen. Without screen it works! A: Your terminals termcap/terminfo entry does not advertise color support properly. 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: 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 characters minus/plus/pipe graphics font character line art lqqqwk +---++ )0lqqqwk displayed in three x a xx | : || x a xx versions. The 3rd tqqqnu +---++ tqqqnu uses ANSI codes. mqqqvj +---++ mqqqvj)B If you get `only strange 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=``aaffggjjkkllmmnnooppqqrrssttuuvvwwx xyyzz{{||}}~~..--++,,hhII00: and the terminfo entry needs to contain smacs=^N, rmacs=^O, enacs=\E(B\E)0, acsc=``aaffggjjkkllmmnnooppqq rrssttuuvvwwxxyyzz{{||}}~~..--++\054\054hhII00, If you see `crude minus&pipe graphics' (like in the second block), screen's own entry is correct (at least your application sent the right codes). But screen believes that the physical terminal could not display real ANSI line graphics, as this requires the use of the alternate character set and 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: 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: If I leave screen too long detached it mysteriously dissappears, although I feel that is not a flaw in the program but rather my system being 'cleaned' of stray jobs. A: Possibly your shells inside screen 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. Possibly your shells are o.k., screen is still running, but you still cannot re-attach your session, as the directory containing your screen socket/fifo (e.g. /tmp/) is cleared regularily. Then check 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 or -CLD on some systems). Screenpid is the process-id of the screen process found in a 'ps -x' listing (it is pe -e on some systems). But this may not work ("Not owner"), when screen is installed set-uid root, as it should be. 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 as a command line argument or by using a switch of some sort. A: Just put the following line in your ~/.screenrc: startup_message off Many people ask this, although it is in the man page, too :-) Q: 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. This is seldom asked, although it is *not* in the man page. Ususally people are satisfied when screen only sources their .cshrc file. 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: 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 ap- plication. Setting the terminal size does not help. A: Probably you got the 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 appli- cation and how screen were linked. Beware, if your applica- tion 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 en- vironment 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 applica- tions that run under screen must be able to adapt their con- trol codes to screen. The application should use the TERM vari- able 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 data- bases. If your application uses hardcoded control codes rather than a database, you are on your own. Hint: The codes under- stood 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" in- stalled 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 compati- ble. 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. Even if the entry was good enough for your application to drive the terminal directly, screen may find flaws, as it tries to use other capabilities while op- timizing the screen output. The screenrc commands "termcap" and/or "terminfo" may help to fine-tune capabilities without calling the supervisor to change the database. 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/ncurses.html, 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: 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: When reattaching a session from a different Workstation, the DISPLAY environment variable should be updated. 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. This however cannot affect the environment of the shells or applications already running under screen. Subsequently spawned processes will reflect the changes. One should be aware of this problem when running applications from very old shells. Screen is a means for keeping processes alive. Q: About once every 5 times I ran the program, rather than getting a "screen," I got someone elses IRC output/input. A: What probably 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: 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 you display which do not belong to any screen window. 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: 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: 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 ESC \ Screen versions after 3.5.12 may provide a workaround. 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 $WINDOW on %m:%c3ESC\\%}%h (%m:%.)%# " else set prompt="%h (%m:%.)%# " endif (Note that ESC means a real ESC (otcal 033) chars). 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: How can I set screen to have shell tcsh for every new window? A: RTFM. You'll find a total of three different ways there: 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'. Of course this relies on having tcsh in your search path. If not, just specify the complete path instead of the word 'tcsh'. 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 2048 characters. Q: On AIX 4.1.2, screen compiles fine, but when run, it only displays a blank page and hangs. A: On AIX 4.1.2, the select() system call does not seem to work on ptys as expected, it never indicates that there is output from the processes. Stuart Hickinbottom <hickinbott@lgwct.logica.com> suggests to poll the ptys 8 times per second with a read() system call. Q: I cannot start screen, it only tells me ``bind(/some/path/name): Invalid argument'' -- What is wrong? A: Screen tried to create a unix domain socket at the pathname shown. The filesystem where this path belongs to does not support sockets. AFS does not support sockets, NFS may, but UFS should. For temporal testing purpose you may override the directory where sockets are created with the SCREENDIR environment variable. For permanent change, edit the definition of SOCKDIR in config.h and compile again. If nothing helps, try using named pipes instead of sockets. Edit config.h and uncomment the definition of NAMEDPIPE. Q: I have a 7-bit terminal that can switch charsets and I'd like to see the german umlaut characters (a-dieresis, etc..) from the iso latin1 character set. Can screen do the trick? A: Yes, see the manual section about Character Translation. (XC termcap capability). 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: The cursor left key deletes the characters instead of just moving the cursor. A redisplay (^Al) brings everything back. A: Your terminal emulator 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 lines termcap <TERM> 'bc@:bs@' terminfo <TERM> 'bc@:bs@' to your ~/.screenrc (replace <TERM> with the terminal type your emulator uses). Q: I have an old SysV OS (like Motorola SysV68) and sometimes screen doesn't reset the attributes correctly. A redisplay (^Al) doesn't make things better. 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 Q: Somtimes when I select the window number 4, the screen session dies. Q: Yes, window 4 is more dangerous than ohter windows. This is a "feature" of all vt100 style keyboards. You accidently used CTRL-A CTRL-4 instead of CTRL-A 4 to select the window. CTRL-4 happens to be the same keycode as CTRL-\, and CTRL-A CTRL-\ is bound to the 'quit' command per default. Add the line bind '^\' to your screenrc file, as the example of our etcscreenrc suggests.