XZY_403

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

XZY_403