1 jw 21.10.93 2 05.05.94 3 4 screen: frequently asked questions -- known problems -- unimplemented bugs 5=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 6 7 8Q: Why is it impossible to download a file with Kermit/sz/rz when 9 screen is running? Do I need to set some special variables? 10 11A: Screen always interprets control-sequences sent by the 12 applications and translates/optimizes them for the current 13 terminal type. Screen always parses the user input for its 14 escape character (CTRL-A). Both are basic screen features and 15 cannot be switched off. Even if it were possible to switch 16 screen into a completely transparent mode, you could never switch 17 between windows, while kermit/sz/rz is downloading a file. You 18 must wait til the end as kermit/sz/rz will not transmit your 19 input during a file transfer and as kermit/sz/rz would be very 20 confused if screen switched away the window containing the 21 other kermit/sz/rz. Simply detach your screen session for each 22 file transfer and start the transfer program only from the shell 23 where you started screen. 24 25Q: I am using screen with a YYY terminal, which supports the XXX 26 graphic language. I am very happy with it, except one thing: I 27 cannot render graphics into screen windows. 28 29A: You are out of luck there. Screen provides a fixed set of escape 30 sequences in order to make it possible to switch terminal types. 31 Screen has to know exactly what the escape sequences do to the 32 terminal because it must hold an image in memory. Otherwise 33 screen could not restore the image if you switch to another 34 window. Because of this you have to change screens escape 35 sequence parser (ansi.c) to pass the XXX graphics sequences to 36 the terminal. Of course the graphics will be lost if you switch 37 to another window. Screen will only honour graphics sequences 38 that are demanded by an overwhelming majority. 39 40Q: For some unknown reason, the fifo in /tmp/screens/S-myname is 41 gone, and i can't resume my screen session. Is there a way to 42 recreate the fifo? 43 44A: Screen checks the fifo/socket whenever it receives a SIGCHLD 45 signal. If missing, the fifo/socket is recreated then. If screen 46 is running non set-uid the user can issue a 'kill -CHLD 47 screenpid' directly (it is -CHILD on some systems). Screenpid is 48 the process-id of the screen process found in a 'ps -x' listing. 49 But usually this won't work, as screen should be installed set- 50 uid root. In this case you will not be able to send it a signal, 51 but the kernel will. It does so, whenever a child of screen 52 changes its state. Find the process-id (shellpid below) of the 53 "least important" shell running inside screen. The try 'kill 54 -STOP shellpid'. If the fifo/socket does not reappear, destroy 55 the shell process. You sacrify one shell to save the rest. If 56 nothing works, please do not forget to remove all processes 57 running in the lost screen session. 58 59Q: When you start "screen" a page of text comes up to start you 60 off. Is there a way to get rid of this text as a command line 61 argument or by using a switch of some sort. 62 63A: Just put the following line in your ~/.screenrc: 64 startup_message off 65 Many peole ask this, although it is in the man page, too :-) 66 67Q: Start "screen emacs" and run emacs function suspend-emacs 68 (ctrl-z). The window containing emacs vanishes. 69 70A: This is a known bug. Unfortunatly there is no easy fix 71 because this is specified in the POSIX standard. When a new 72 window is created Screen opens up a new session because the 73 window has to get the pty as a controlling terminal (a 74 session can only have one controlling terminal). With the 75 setsid() call the process also creates a new process 76 group. This process group is orphaned, because there is no 77 process in the session which is not in the process 78 group. Now if the process group leader (i.e. your program) 79 gets a TTIN/TTOU/TSTP, POSIX states that the kernel must 80 send a KILL signal to the process group because there is no 81 one left to continue the process. Even if screen would 82 try to restart the program, that would be after it received the 83 KILL signal which cannot be caught or ignored. 84 85 tromey@klab.caltech.edu (Tom Tromey): I've noticed this exact 86 same problem. I put this in my .emacs file. It seems to work: 87 88 ;; If running under screen, disable C-z. 89 (if (and (getenv "STY") (not window-system)) 90 (global-unset-key "\C-z")) 91 92Q: Screen gets the terminal size wrong and messes up. 93 94A: Before you start screen: Check with 'stty -a' what the terminal 95 driver thinks about rows and columns. Check the environment 96 variables LINES and COLUMNS. Then from within screen check with 97 the info command (CTRL-A i) what size screen thinks your terminal 98 is. If correcting tty driver setting and environment variables 99 does not help, look up the terminal capability definition. First 100 the TERMCAP environment variable. If this is not set, look up the 101 terminals name as defined in the environment variable TERM in 102 /etc/termcap or in the terminfo database with untic or infocmp. 103 There may be :li=...: and :co=...: or even :ll=...: entries 104 (cols#... and lines#... when it's terminfo) defined incorrectly. 105 Either construct your own TERMCAP environment variables with 106 correct settings, use screens terminfo/termcap command in your 107 .screenrc file or have the database corrected by the system 108 administrator. 109 110Q: Screen messes up the terminal output when I use my favourite ap- 111 plication. Setting the terminal size does not help. 112 113A: Probably you got the termcap/terminfo entries wrong. Fixing this 114 is a three stage procedure. First, find out if terminfo or 115 termcap is used. If your system only has /etc/termcap, 116 but not /usr/lib/terminfo/... then you are using termcap. 117 Easy. But if your system has both, then it depends how the appli- 118 cation and how screen were linked. Beware, if your applica- 119 tion runs on another host via rlogin, telnet or the like, you 120 should check the terminfo/termcap databases there. If you cannot 121 tell if terminfo or termcap is used (or you just want to be 122 save), the do all steps in stage 3 in parallel for both 123 systems (on all envolved hosts). Second: Understand the basic 124 rules how screen does its terminal emulation. When screen is 125 started or reattached, it relies on the TERM environment variable 126 to correctly reflect the terminal type you have physically 127 in front of you. And the entry should either exist in the system 128 terminfo/termcap database or be specified via the TERMCAP en- 129 vironment variable (if screen is using the termcap system). On 130 the other end, screen understands one set of control codes. It 131 relies on the application using these codes. This means applica- 132 tions that run under screen must be able to adapt their con- 133 trol codes to screen. The application should use the TERM vari- 134 able and termcap or terminfo library to find out how to drive 135 its terminal. When running under screen, the terminal is virtual 136 and is only defined by the set of control codes that screen 137 understands. The TERM variable is automatically set to 138 "screen" and the "screen"-entries should exist in the data- 139 bases. If your application uses hardcoded control codes rather 140 than a database, you are on your own. Hint: The codes under- 141 stood by screen are a superset of the very common definition 142 named "vt100". Look at the documentation of screen. The 143 codes are listed there. Third: Have the entry "screen" in- 144 stalled on all hosts or make sure you can live with "vt100". 145 Check the codes sent by your application, when the TERM variable 146 is set to "screen". Do not try to set the TERM variable inside 147 screen to anything other than "screen" or "vt100" or compati- 148 ble. Thus your application can drive screen correctly. Also take 149 care that a good entry is installed for your physical terminal 150 that screen has to drive. Even if the entry was good enough 151 for your application to drive the terminal directly, screen may 152 find flaws, as it tries to use other capabilities while op- 153 timizing the screen output. The screenrc commands 154 "termcap" and/or "terminfo" may help to fine-tune capabilities 155 without calling the supervisor to change the database. 156 157Q: I cannot configure screen. Sed does not work. 158 159A: The regular expressions used in our configure scrip are too 160 complicated for GNU sed version 2.03. In this regard it is bug 161 compatible with Ultrix 3.1 "sed": GNU sed version 2.03 dumps 162 core with our configure script. Try an older release. E.g. from 163 ftp.uni-erlangen.de:/pub/utilities/screen/sed-2.02b.tar.gz 164 165Q: When reattaching a session from a different Workstation, the 166 DISPLAY environment variable should be updated. Even ``CTLR-A 167 : setenv DISPLAY newhost:0'' does not work as expected. 168 169A: Under unix every process has its own environment. The environ- 170 ment of the SCREEN process can be changed with the `setenv' com- 171 mand. This however cannot affect the environment of the 172 shells or applications already running under screen. Subsequently 173 spawned processes will reflect the changes. One should be aware 174 of this problem when running applications from very old shells. 175 Screen is a means for keeping processes alive. 176 177Q: About once every 5 times I ran the program, rather than getting 178 a "screen," I got someone elses IRC output/input. 179 180A: What probably happened is that an IRC process was left running on 181 a pseudo tty in such a way that the kernel thought the tty was 182 available for reallocation. You can fix this behaviour by 183 applying the SunOS 4.1.x tty jumbo patch (100513-04). 184 185Q: Screen compiled on SunOS 5.3 cannot reattach a detached session. 186 187A: You are using /usr/ucb/cc, this compiler is wrong. Actually it 188 links with a C-library that mis-interprets dirent. Try again 189 with /opt/SUNWspro/bin/cc! 190 191Q: The "talk" command does not work when Screen is active. 192 193A: Talk and several other programs rely on entries in the Utmp- 194 Database (/etc/utmp). On some systems this Database is world 195 writable, on others it is not. If it is not, screen must be 196 installed with the appropriate permissions (user or group s-bit) 197 just like any program that uses PTYs (rlogin, xterm, ...). When 198 screen cannot write to utmp, you will see messages on you display 199 which do not belong to any screen window. 200 When screen can update utmp, it is not guaranteed that it does as 201 you expect. First this depends on the config.h file defining 202 UTMPOK, LOGINDEFAULT, and perhaps CAREFULUTMP. Second it depends 203 on the screenrc files (system wide and per user), if utmp entries 204 are done. Third, you can control whether windows are logged in 205 with screens ``login'' command. 206 207Q: Seteuid() does not work as expected in AIX. Attempting a multi- 208 user-attach results in a screen-panic: "seteuid: not owner". 209 210A: This is not a screen problem. According to Kay Nettle 211 (pkn@cs.utexas.edu) you need the AIX patch PTF 423674. 212 213Q: When I type cd directory (any directory or just blank) from 214 within one of the windows in screen, the whole thing just freezes 215 up. 216 217A: You display the current working directory in xterm's title bar, 218 This may be caused by hardcoded ESC-sequences in the shell prompt 219 or in an cd alias. In Xterm the coding is 220 ESC ] n ; string_to_display ^G 221 where n = 1, 2, 3 selects the location of the displayed string. 222 Screen misinterprets this as the ansi operating system comment 223 sequence: 224 ESC ] osc_string 225 and waits (according to ansi) for the string terminator 226 ESC \ 227 Screen versions after 3.5.12 may provide a workaround. 228 229Q: Mesg or biff cannot be turned on or off while running screen. 230 231A: Screen failed to change the owner of the pty it uses. You need to 232 install screen setuid-root. See the file INSTALL for details. 233 234Q: The cursor left key deletes the characters instead of just moving the 235 cursor. A redisplay (^Al) brings everything back. 236 237A: Your terminal emulator treats the backspace as "destructive". You 238 can probably change this somewhere in the setup. We can't think 239 of a reason why anybody would want a destructive backspace, but 240 if you really must have it, add the lines 241 termcap <TERM> 'bc@:bs@' 242 terminfo <TERM> 'bc@:bs@' 243 to your ~/.screenrc (replace <TERM> with the terminal type your 244 emulator uses). 245 246Q: I have an old SysV OS (like Motorola SysV68) and sometimes screen 247 doesn't reset the attributes correctly. A redisplay (^Al) doesn't 248 make things better. 249 250A: The libcurses library has a bug if attributes are cleared with 251 the special ue/se capabilities. As a workaround (other than upgrading 252 your system) modify 'rmul' (and 'rmso'?) in screen's terminfo entry: 253 rmul=\E[m, rmso=\E[m 254