some bugs you should know about. they make a great reason to update, too!
latest version: do not let old bugs bite you - check whether the problem exist with the *latest* version, too! use recommended programs to go along with screen and stay away from programs for which there are many unresolved bug reports. ;-)
system info: uname -a
screen version: screen -v
screen binary: show which screen is getting called: let "which" show the /path/file of "screen": which screen let "ls" show its full /path/file, too: ls -l `which screen`mind you, this might be a shell alias or a shell function. and "which" may be an external command which does not check the these within the shell. :-(
please use bash, ksh, or zsh - the tcsh is somewhat silly and the csh is just plain broken in many respects.
if "screen" is a link then also let "ls" resolve that link to its final target: ls -lL `which screen`
for use with zsh - let it show you *all* screen binaries in the shell's $PATH: which -a screen
are you logged in at the machine directly on a console?
$ tty /dev/tty1
or are you using screen on a remote session? are you connecting to a machine running screen from the outside, that is did you start screen before making any connections and starting programs on the remote host?
or are you using screen inside a terminal of the GUI screen? which terminal do you use? aterm? eterm? rxvt? xterm? xterm-color? give its version number, too!
which program do you use to connect? windows: putty, teratermpro, telnet.exe? unixish: openssh, ssh, telnet, rsh?
what does the shell know about your terminal? echo $TERM
which login shell do you get after login? grep $USER /etc/passwd
does the shell setup set a fixed value for TERM? check all the files (TODO) set the DEBUG value and start your login shell not just with "$SHELL" but as a login shell, ie something like "$SHELL --login" (depends on the shell used, really) and check the output for files it reads. check all those files for "TERM" then.
Frequently Asked Questions when problems occur:
do you use screen as your login shell? does your login shell call screen directly? what do the programs inside of screen get to know about your terminal? again - "echo $TERM" does $TERM really match the terminal you use? example: local system: debian 3.0 unstable local terminal: xterm 4.1.0(165) TERM=xterm connecting with: OpenSSH_3.0.1p1 remote system: SunOS ritz 5.8 Generic_108528-13 sun4u sparc TERM=xterm screen-3.09.11 TERM=screen do you get problems with the display of your programs running inside of screen? do these programs make use of ncurses or the slang library? -> ldd did you check the SCREEN FAQ? did you read the SCREEN info docs? did you look at the SCREEN Pages? did you search the web with a search engine such as Google? did you look a the mailing list archive? and most importantly: did you read the SCREEN HOWTO? did you read about how to ask questions in a smart way? http://www.catb.org/~esr/faqs/smart-questions.html did you check *this* page and did you follow all of the advice? ;-) "it works fine": well - how do you know? are you assuming this - or did you run any tests to verify this? what exactly did you test? and how? what kind of setup do you use? do you use no setup files at all? (neither /etc/screenrc nor $HOME/.screenrc?) do you use the standard setup from the installation? do you use your own $HOME/.screenrc? do you happen to use someone else's setup? (eg www.guckes.net/setup/screenrc ?) which parts of your setup would probably affect the bug you are reporting? please test: does your error occur when you start screen ignoring all setup files? did you check that you get the right binary? -> which screen, echo $PATH did you install the binary yourself? or has screen been installed already? if so - how? include config parameters. if not - was screen installed from a package? which? (Debian DEB? RedHat RPM?) PERMISSIONS what are the permission of the binary? $ ls -lL `which screen` and what are the permission of the directories (eg $SCREENDIR) and files (~/.screenrc). $ ls -lL /etc/screenrc $HOME/.screenrc or did you copy the binary from some other machine or from another user? ERROR MESSAGES do you get any error messages? which? please try to reproduce these error messages and give a possibly minimal set of commands which expose them. getting error matches from screen into your bug report: use the shell "redirection" of stderr (error channel) into a file. use SCREEN's commands "hardcopy" and "log" to get data from your screen into a file. copy&paste from the terminal. INSTALLATION did you get any error with the "configure && make && make install"? (check the file "config.log"!) did you "rehash" your shell before starting the binary again? REPORTING huge config files, screenshots -> upload to web server, post addresses. do not append files inline with the message but *attach* them! please avoid posting large amounts of data! upload the complete compiler logs to your website and include the web address so we can download it if we should be missing any parts of that. please start your report with a new mail. do NOT reply to some old mail from the list because then the new mail will have a reference to the old mail and the "new" thread will be grouped together with old mail which results in problems. do not start your thread by replying to just any message on the list. after all you can copy&paste the mailinglist address using screen easily into your mail program. and with good mailers you can also create an alias so all it takes is an address like "MLscreen" [mailing list (for) screen] in the To: line: # alias for mailing list for the mutt mailer: alias MLscreen GNU Screen MailList <gnu-screen@yahoogroups.com>
Please be patient! Do not rush or threaten us!
Reporting the same question on the list three times a week and telling us that we should have to respond just does *not* work. Demands and threats just makes us ignore you more than before.
After all we are not getting paid for this and the list is not part of some "customer support" with which we are making money. This is free software and I doubt you have paid anything for it.
frequent problems: binding keys getting colors to display correctly libraries: gettext, ncurses, slang terminals: unicode, backspace vs delete
DANGER! Use of the builtin telnet command crashes the session when no hostname is given: ":screen //telnet"
Example:
:bufferfile $HOME/foo Bufferfile is now '/tmp/screen-exchange'
command: :screen lynx message: Cannot exec lynx: No such file or directory
You might wonder why screen would want to execute a directory. Well, this error message is from a library (libc) and thus is not SCREEN's fault.