Red Hat Bugzilla – Bug 77833
screen quirks, specificly problems with backspace and scrollbars on terminal windows
Last modified: 2007-04-18 12:48:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20021017
Description of problem:
I have started using a setup where I always have screen running on top of zsh in
a way that if I type exit the terminal window closes, saving me from having to
type exit to terminate screen and then exit to terminate the shell. As a result
I have started to notice all screen's quirks. The first being backspace works in
the command line, but if you run "man screen", type /asdf, and then hit
backspace you get ^H^H^H. This can be fixed by "stty erase ^H", but if you add
this to a profile it breaks command line functionality for other terminal types.
So the correct way to handle this with an if statement to check $TERM to see if
it is screen and if so issue the stty command. I propose a /etc/profile.d script
should be created to handle the workarounds for screen's quirks. This also
affects ssh connections because the $TERM is transfered across so all machines
connected to need to handle the screen terminal type right.
Another quirk is that screen by default prevents terminal windows from
scrollbars from working. A simple workaround would be to add termcapinfo xterm
ti@:te@ to /etc/screenrc
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start X
2. Open a terminal window
3. Run screen
4. Run man screen
5. Type /asd<backspace><backspace><backspace>
6. Type <delete><delete><delete><delete><delete><delete><delete>
7. Type q
8. Run ls -alR
Actual Results: You get ^Hs. The scrollbar doesn't shrink and can't be used to
Expected Results: It to delete the characters and the scrollbar to work.
Both of these problems are related to the termcap info for screen. Maybe you can
come up with fixes that are closer to the roots of the problems.
It would be nice if these were fixed soon so they would be sure to be in the
next release and I don't have to install these workarounds on every machine I
work on forever.
Screen's lack of use of the controlling terminal's scrollback buffer is, I
believe, intentional. Consider the following situation:
screen 0: ls /lib
<switch to 1>
screen 1: cat /usr/src/linux-2.4/Makefile
<switch to 0>
<scroll back using gnome-terminal or xterm's scrollback>
In this case, the information above the current screen which can be seen using
xterm/gnome-terminal's scroll bar is parts of the Linux kernel makefile, instead
of the contents of /lib.
Luckily, has per-window scrollback buffers. Switch to the window you want, and
press <Ctrl-A> <Escape> to enter scrollback/copy mode.
Will get back to you on the ^H thing soon.
It seems you are right about the scrollback. It does seem to handle scrollback
properly between screen 0 and screen 1 if using ls in both. But as you suggest
using ls in one and cat in the other gives the mixed results. I don't plan on
using more than one screen per window. So I will add it to my /etc/screenrc and
live with that.
Uncommenting lines 71,72 seem to achieve the same effect.
The ^H problem is interesting. In order for it to not appear (ie, work
correctly), you have to be sourcing /etc/bashrc... Which isn't really a good
option for a zsh user. This is because currently only bash sets the backspace
stty erase `tput kbs`
Placing that line in /etc/zshrc and /etc/csh.cshrc solves the problem for those
shells. Alternatively (not recommended):
Change lines 222, 223: of /etc/screenrc:
bindkey -d -k kb stuff "\177"
#bindkey -d -k kb stuff "\177"
This will break it for bash users, but fix it for everyone else. To change it
for you specifically, place:
bindkey -k kb stuff "\177"
in ~/.bashrc. I'll see what we can do for zsh/tcsh/etc. in future releases.
Let me know if this works for you at the moment.
Yes, adding stty erase `tput kbs` to /etc/zshrc fixes the problem and doesn't
cause it to work in screen but not in a normal shell. So your fix is better than
my if statement method.
bindkey -k kb stuff "\177"
This will break all programs running inside screen, that respect $TERM,
because TERM=screen specifies that backspace has the code ^H and that
is what programs will expect.
You have any examples? It seems to work fine to me.
login on VT1, start screen, type something ( I have bash as my shell )
move the cursor in the middle of what is typed, press "Delete".
It should delete the char to the right, but does something else,
don't remember exactly what.
Sorry I confused things, ignore my last message.
As for the 'bindkey -d -k kb stuff "\177"' line, it is wrong.
'bindkey -k kb stuff ^H' is correct.
If any program misbehaves with the second option, then that program is buggy.
This has already been discussed in bug # 11294
chaos , here are the examples :
Question : Does the backspace key work properly ?
env 0 - linux console on VT1
env s0 - screen running on VT1 , no 'bindkey -d -k kb stuff ...' line in
env s1 - screen running on VT1 , 'bindkey -d -k kb stuff \010' line in screenrc
env s2 - screen running on VT1 , 'bindkey -d -k kb stuff \177' line in screenrc
( for reference \010==^H and \177==^?==DEL )
application | env 0 | env s0 | env s1 | env s2
vi | yes | no | yes | no
bash | yes | yes | yes | yes
tcsh | yes | yes | yes | yes
less | yes | no | yes | no
cat | yes | no | yes | no
jed | yes | yes | no | yes
joe | yes | yes | yes | yes
make | yes | yes | yes | yes
menuconfig ( select Load Configuration and edit the filename )
as you see , binkdey to \177 breaks 3 programs out of 8 programs that I
have "randomly"(*) choosen, while the "correct" setting of bindkey \010 works
with 7, that is all except jed, which seems to have hardcoded the HELP function
* - I selected all programs that I could remember that have some kind of text
I just tried putting 'bindkey -d -k kb stuff \010' into /etc/screenrc. Then I
restarted my terminal windows. Backspace worked on the command line, but again
not when doing man screen, type / for search, type some characters like asdf,
and hitting backspace. I would again get ^H. So in my opinion 010 isn't the
right fix. I am using konsole, zsh, and screen together like 'konsole -e screen
-e^Xx'. konsole runs and calls screen which is set with an alternative key so I
don't have problems with screen remotely and screen calls zsh. At first I tried
adding 010 to /etc/zshrc, but zsh didn't like the -k for bindkey.
With stty erase `tput kbs` back in /etc/zshrc backspace works everywhere it
seems. I tried vi, tried bash, tried tcsh, tried less, and tried man. The only
thing I have noticed recently is vi has started acting quirky, but don't think
it is related to this.
We're considering adding the stty erase `tput kbs` into zshrc, since it seems to
work in all cases tested thus far.
stty erase `tput kbs` works allways ( except if the TERM variable is wrong )
and should be used for startup scripts of all shells.
That leaves the problem when the program running on a terminal is not a shell.
Is it possible to "embed" the stty command into the terminal opening procedure ?
In zsh-4.0.6-1, "stty erase `tput kbs`" is now included in /etc/zshrc.
(Should be in rawhide before long.)
I have found more issues with screen and I have found a final solution, I think.
One problem is on the command line delete acts like backspace. Another is that
delete in vi while in INSERT mode gives a ^? instead of delete behavior. I also
randomly get things like H instead of the Home key action in vi. In general
screen is really quirky. I found I could get rid of all the problems, including
the need for stty erase `tput kbs` in /etc/zshrc by using the standard screenrc
from 3.9.13 instead of the modified one in the redhat package. I suspect that
just not replacing the normal screenrc that comes with 3.9.11 with a redhat
version will also fix all these annoying bugs.
I'll eval 3.9.13 and see if it fixes any of the major problems we see with
3.9.11, as well as figure out the differences between the default config files.
Thanks for the info!
The "delete" key problem is known and fiex. See bug #78423
Well I still seem to have the H instead of home and F instead of End problem
while using screen and in vi. If you hit Escape, Home, and End repeatedly in
order you should see it within four tries. I just tried it with 3.9.13 and it's
screenrc, same problem.
After looking over #78423 and seeing the fix for the delete problem was to remove
bindkey -d -k kD stuff "\177" I looked in /etc/screenrc and found
# This makes screen treat backspaces '^?' as
# deletes. There should be a fix in the code
# for the way termcap inheritance works,
# but I dont know where to put it, and this works.
bindkey -d -k kb stuff "\010"
bindkey -d -k kD stuff "\177"
By commenting out both bindkeys it fixes the delete problem and the backspace
problem when doing man screen /asf^H^H^H.
What backspace problem ?
I have standard RHL8.0 ( with screen-3.9.11-10 and its standard
installed /etc/screenrc ) and I see no problem with backspace in man screen.
I also can't reproduce the Home/End problem in vi ( or in vim ).
Tell us more about your environment
I am using RedHat 8.0, screen-3.9.11-13, zsh, and konsole.
I call it with
konsole -T Terminal1 -e screen -e^Xx &
This opens a konsole with screen as the shell, and screen opens zsh. The Xx is
to rebind the main hotkey so I can use ^A, the default, on other systems.
I just tried commenting out these lines in my /etc/zshrc that I thought might
cause my home/end problem, but it didn't help.
bindkey "^[[5~" up-line-or-history ## PageUp
bindkey "^[[6~" down-line-or-history ## PageDown
bindkey "\e[1~" beginning-of-line
bindkey "\e[H" beginning-of-line
bindkey "\e[2~" transpose-words
bindkey "\e[3~" delete-char
bindkey "\e[4~" end-of-line
bindkey "\e[F" end-of-line
Sigh, screen is such a mess. I am not sure this will get fixed right any time
soon, because of all the old versions of RedHat that you have to deal with
remotely. I now have a problem with backspace in vi when on a remote machine. ^?
was mentioned in the comment for the lines in /etc/screenrc I commented out.
I found even with
stty erase `tput kbs` in /etc/zshrc
bindkey -d -k kD stuff "\177"
causes problems. If I comment out
bindkey -d -k kD stuff "\177"
backspace/delete work both locally and remotely.
I can leave
bindkey -d -k kb stuff "\010"
in without a problem.
I tried "xterm -Tsomething -e screen -e^Xx" and did not see any problems with
Home or End in vim. I do not have zsh or konsole installed.
( the -T option is meaningless because screen puts it own status line into the
window title )
Do you see the problem with bash and xterm ( or text console ) too ?
What keyboard layout are you using ( /etc/X11/XF86Config ) ?
Does the bug involve any remote sessions or is everything local ?
About the "bindkey -d -k kD stuff "\177"" line : it is a bug, delete it and
forget it ever existed.( see bug #78423 )
Aha , the terminfo data for 'konsole' does not mention HOME :
[root@localhost root]# infocmp konsole | grep khome
This means HOME works by accident at most in 'konsole'.
It is the same for END.
[root@localhost k]# rpm -qf /usr/share/terminfo/k/konsole
termcap has no entry for 'konsole'
[root@localhost k]# rpm -qf /etc/termcap
Please try if you have any problems without 'konsole' and file a bug
for 'konsole', 'termcap' or 'ncurses'. ( or all of them :-) )
Actually the -T works with konsole. The string comes out
[screen 0; zsh] - Terminal1 - Konsole
I have sawfish match the window title by it to place the windows on the right
workspace and in the right place. I end up with a layout like:
I don't get issues with vi and HOME/END when using
xterm -e screen -e^Xx
Which the above was using zsh since that is my shell and I didn't specific bash.
The -Tsomething with xterm caused it not to even start for me.
These are my keboard settings from /etc/X11/XF86Config
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "us" #Option "XkbVariant" ""
The reason I use konsole is because gnome-terminal from Gnome2 has issues and
xterm is old and ugly. Though it seems to work better. It doesn't support utf8,
but then again konsole doesn't support it either. I guess I will be in search
for a new terminal again.
Just switched back to gnome-terminal. 2.5.50 or something else seems to have
solved the problem with gnome-terminal, fast scrolling, and mouse freezing.
gnome-terinal resolves the Home/End problem in vi for me.
New version of screen is in rawhide:
The backspace/delete problems should be fixed.
Everything works with screen as it should as far as I know with Phoebe, except
konsole, but that is an issue with Konsole.