diff options
Diffstat (limited to 'doc/FAQ')
| -rw-r--r-- | doc/FAQ | 253 |
1 files changed, 253 insertions, 0 deletions
@@ -0,0 +1,253 @@ + jw 21.10.93 + 05.05.94 + + 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: 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: 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 set- + uid 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 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 peole ask this, although it is in the man page, too :-) + +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: 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: 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: 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 |