Bug 23373 - Delete key *still* doesn't work
Summary: Delete key *still* doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-05 06:19 UTC by rcarpen
Modified: 2005-10-31 22:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-08 15:38:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description rcarpen 2001-01-05 06:19:37 UTC
There has been much discussion about this, and I have yet to see any
results.  The Delete key in RedHat 7.0 produces "\[3~" which is about as
useful as nothing.  How can we get the Delete key to send a "Delete"?  It
is getting so frustrating that Red Hat chooses to break things that
previously worked with earlier releases.  Also, this same bug seems to have
also broken something I have been used to in the past:  hitting control in
conjunction with an arrow key used to simply produce the same thing as the
arrow key alone.  Now, it produces something different ("\[5A" instead of
"\[A" for the up arrow)  Can we please change the behavior of the keyboard
back to the sane way it was and alwasy has been?

Comment 1 Daniel Roesen 2001-01-05 14:27:02 UTC
The new way is the sane way. The old behaviour was broken.

Comment 2 rcarpen 2001-01-05 14:39:24 UTC
How do you figure it is sane to disable the functioning of the Delete key??
How could BackSpace=BackSpace, and Delete=Delete *not* be sane??

I have certain applications that require the use of "Delete" rather than
"BackSpace".  I need both ^? and ^H.  \[~3 doesn't do anything but print a '~'
on the screen.  I don't understand how that could be considered 'sane'.  It
would be nice to be able to swap BS and Delete like was always possible before,
but I at least need both keys functioning.  Please tell me how to make it work.

This reminds of of the xterm termcap bug that was labelled as "the right way to
do it" when all it did was break compatibility with non-linux systems.

Comment 3 Ngo Than 2001-01-15 12:29:36 UTC
i assigned it to correct package.

Comment 4 Michael Fulbright 2001-01-16 00:27:20 UTC
I don't think this has much to do with the installer, more to do with the
keymaps which ship for the console and X.

Comment 5 Tomas Mraz 2001-02-08 10:59:16 UTC
Yes now it's the correct behaviour. The classic DELETE ^? and  Backspace ^H
should do the same thing - delete the character to the left of the cursor. The
"\[3~" is the correct character to delete to the right of the cursor. I have RH
7.0 system too and don't experience any problems with these keys. I've set the
gnome-terminal so the '<-' key on keyboard sends the ^? character and everything
except the PINE works fine. The PINE could be made to work using the following
expect language script:

#!/usr/bin/expect -f

eval spawn -noecho pine -i

interact {
 "\177"      {send "\010"}
 "\033\[3~"  {send "\004"}

Comment 6 rcarpen 2001-02-08 15:16:23 UTC
Ok... if this is the correct behavior, then tell me how I can get the 
Backspace key to send ^H, and the delete key to send ^?, just like it had done 
in every distribution I have ever seen until very recently.  I need both ^H 
and ^? to work properly to do my work.  The "\[3~" does not do anything at all 
at console or in X.  The delete key work properly (deleting the key to the 
right of the cursor) in some X programs like Netscape, etc., but does not work 
in a terminal session.  Any idea about getting the arrow keys to work while 
holding control?

Comment 7 Tomas Mraz 2001-02-08 15:38:49 UTC
Look at the following page maybe it helps you:

Comment 8 Mike A. Harris 2001-09-23 17:39:02 UTC
I'm assuming that this bug is refering to xterm.
I've tested xterm in RHL 7.1 and current rawhide (4.1.0-3) and
xterm in both cases responds properly to the BS and DEL keys,
doing what is correct for both.  My definition of correct being
what a Windows user would expect - BS deleting the char to the left
of the cursor, and DEL deleting the char to the right.  This is
using a 101 key keyboard in the en_US locale.

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