Bug 77833 - screen quirks, specificly problems with backspace and scrollbars on terminal windows
screen quirks, specificly problems with backspace and scrollbars on terminal ...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-14 02:38 EST by Nathan G. Grennan
Modified: 2007-04-18 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-02 22:42:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nathan G. Grennan 2002-11-14 02:38:42 EST
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):


How reproducible:
Always

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
scrollback.

Expected Results:  It to delete the characters and the scrollbar to work.

Additional info:

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.
Comment 1 Lon Hohberger 2002-11-14 13:52:11 EST
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.
Comment 2 Nathan G. Grennan 2002-11-14 14:01:36 EST
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.
Comment 3 Lon Hohberger 2002-11-14 14:57:12 EST
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
key properly:

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.
Comment 4 Nathan G. Grennan 2002-11-14 15:05:34 EST
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.
Comment 5 David Balažic 2002-11-19 08:32:56 EST
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.
Comment 6 Nathan G. Grennan 2002-11-19 12:08:34 EST
You have any examples? It seems to work fine to me.
Comment 7 David Balažic 2002-11-20 17:12:42 EST
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.
Comment 8 David Balažic 2002-11-22 09:20:01 EST
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
Comment 9 David Balažic 2002-11-22 10:57:46 EST
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 
screenrc
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 
to ^H.

* - I selected all programs that I could remember that have some kind of text 
editing support
Comment 10 Nathan G. Grennan 2002-11-22 13:24:02 EST
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.
Comment 11 Nathan G. Grennan 2002-11-22 13:33:52 EST
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.
Comment 12 Lon Hohberger 2002-11-22 15:54:28 EST
We're considering adding the stty erase `tput kbs` into zshrc, since it seems to
work in all cases tested thus far.
Comment 13 David Balažic 2002-11-23 07:34:09 EST
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 ?
Comment 14 Jens Petersen 2002-11-28 03:29:46 EST
In zsh-4.0.6-1, "stty erase `tput kbs`" is now included in /etc/zshrc.
(Should be in rawhide before long.)
Comment 15 Nathan G. Grennan 2002-12-04 02:06:41 EST
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.
Comment 16 Lon Hohberger 2002-12-04 13:48:13 EST
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!
Comment 17 David Balažic 2002-12-04 13:52:16 EST
The "delete" key problem is known and fiex. See bug #78423
Comment 18 Nathan G. Grennan 2002-12-04 16:42:31 EST
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.
Comment 19 Nathan G. Grennan 2002-12-04 17:15:33 EST
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.
Comment 20 David Balažic 2002-12-05 10:18:02 EST
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
Comment 21 Nathan G. Grennan 2002-12-05 18:30:30 EST
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
Comment 22 Nathan G. Grennan 2002-12-05 18:59:47 EST
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.
Comment 23 Nathan G. Grennan 2002-12-05 19:20:42 EST
I found even with

stty erase `tput kbs` in /etc/zshrc

that

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.
Comment 24 David Balažic 2002-12-06 07:44:37 EST
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 )
Comment 25 David Balažic 2002-12-06 08:31:33 EST
Aha , the terminfo data for 'konsole' does not mention HOME :
[root@localhost root]# infocmp konsole | grep khome
[root@localhost root]#

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
ncurses-5.2-28

termcap has no entry for 'konsole'

[root@localhost k]# rpm -qf /etc/termcap
termcap-11.0.1-13

Please try if you have any problems without 'konsole' and file a bug 
for 'konsole', 'termcap' or 'ncurses'. ( or all of them :-) )
Comment 26 Nathan G. Grennan 2002-12-06 08:55:07 EST
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:

1 2
3 4

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.
Comment 27 Nathan G. Grennan 2002-12-06 09:55:48 EST
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.
Comment 28 Lon Hohberger 2002-12-16 16:36:36 EST
New version of screen is in rawhide:

ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/screen-3.9.13-2.i386.rpm

The backspace/delete problems should be fixed.
Comment 29 Nathan G. Grennan 2003-01-02 22:42:04 EST
Everything works with screen as it should as far as I know with Phoebe, except
konsole, but that is an issue with Konsole.

Note You need to log in before you can comment on or make changes to this bug.