Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 160354 - backspace key in vim running from xterm returns ^?
Summary: backspace key in vim running from xterm returns ^?
Keywords:
Status: CLOSED DUPLICATE of bug 155538
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: 4
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
URL:
Whiteboard:
: 162549 163812 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-14 16:37 UTC by Tom Mount
Modified: 2007-11-30 22:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-24 10:36:50 UTC


Attachments (Terms of Use)
patched XTerm file (deleted)
2005-07-02 00:46 UTC, Tom Mount
no flags Details | Diff

Description Tom Mount 2005-06-14 16:37:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
When I run vim from the xterminal, anytime I hit the backspace key I get ^? on the screen instead of backspacing. The delete key will delete the current character; if there is no character under the cursor it acts like a backspace key. When I ran vim from gnome-terminal, I do not have this problem. "tput kbs|cat -v ;echo" returns ^?, like it should.

Version-Release number of selected component (if applicable):
xterm-200-6

How reproducible:
Always

Steps to Reproduce:
1. start xterm
2. run vi
3. in insert mode, hit <backspace> key
  

Actual Results:  screen displays ^?

Expected Results:  the previous character should have been deleted

Additional info:

Comment 1 Jared Sutton 2005-06-14 16:39:30 UTC
I verified this problem with a clean install of FC4.

Comment 2 Jared Sutton 2005-06-14 16:53:59 UTC
In addition, the problem also exists when ssh'ing into a different box and
running vi.

For example, I'm on a FC4 box, with an xterm open, and I ssh
user@another_FC4_box.mydomain.foo, and I start editing a doc in vi, the same
problem exists.

Comment 3 Gravis 2005-06-16 19:38:51 UTC
Same problem here, with a fresh new install. Sounds like an inputrc problem.

cheers

Comment 4 Nick Lamb 2005-06-16 21:50:26 UTC
You can add the following line to the file .Xdefaults
*ttyModes:              erase 

... or wait for someone to fix bug 155538

Comment 5 Gravis 2005-06-18 15:10:38 UTC
Adding to .Xdefaults didn't work for me. Nevertheless, this is working here :
add

*ttyModes: erase ^?

to

/usr/X11R6/lib{,64}/X11/app-defaults/XTerm

(as explained in 155538. Thank you Nick.

Comment 6 Jared Sutton 2005-06-18 17:12:59 UTC
adding that line as referenced in the previous post also fixed the problem here
too (both at the machine, and over ssh).  Perhaps this should be patched, and an
update for xterm should be released.

Comment 7 Mike A. Harris 2005-06-22 20:41:10 UTC
(In reply to comment #5)
> Adding to .Xdefaults didn't work for me. Nevertheless, this is working here :
> add

.Xdefaults hasn't been supported by XFree86 or Xorg for 5 years or so.
The correct file is ~/.Xresources

HTH

Comment 8 Adam Pribyl 2005-06-26 19:39:59 UTC
This is also problem in man find function (/).

In vim :help fixdel is how to fix that either for vim only or this note:
"Note about Linux: By default the backspace key
produces CTRL-?, which is wrong.  You can fix it by
putting this line in your rc.local: >
echo "keycode 14 = BackSpace" | loadkeys"

Comment 9 Tom Mount 2005-07-02 00:46:33 UTC
Created attachment 116272 [details]
patched XTerm file

Comment 10 Tom Mount 2005-07-02 00:47:52 UTC
Comment on attachment 116272 [details]
patched XTerm file

path should be /usr/X11R6/lib/X11/app-defaults/

Comment 11 Noa Resare 2005-07-07 19:50:03 UTC
*** Bug 162549 has been marked as a duplicate of this bug. ***

Comment 12 Michael Stevens 2005-07-08 11:12:21 UTC
I'm also seeing this bug on a FC3->FC4 upgrade.

The xterm*ttyModes: erase ^?
workaround fixes it.

Comment 13 Michael Stevens 2005-07-08 11:12:47 UTC
I'm also seeing this bug on a FC3->FC4 upgrade.

The xterm*ttyModes: erase ^?
workaround fixes it.

Comment 14 Karsten Hopp 2005-07-21 12:23:38 UTC
*** Bug 163812 has been marked as a duplicate of this bug. ***

Comment 15 Radu Cornea 2005-08-12 02:04:34 UTC
The problem is NOT xterm, is that the /etc/termcap entry for xterm is not
synchronized with terminfo entry (look at the "kb" value).

The fix is to replace "kb=^H" with "kb=^?" in /etc/termcap, for the
"xterm-basic" entry (which is included by xterm, through xterm-old).

To verify: "infocmp xterm | grep kbs" displays "kbs=\177".

Probably this bug should be assigned to the termcap maintainer.

(Please make sure that the xterm-256color entry is also fixed)


Comment 16 Petr Raszyk 2005-08-30 07:41:59 UTC
To comment #15:

Yes, you are right.
This is a bug in termcap. I have received this as Bug #166702.

Fixed in termcap 5.4 Rel.5.

Petr Raszyk


Comment 17 Mike A. Harris 2005-09-24 10:36:50 UTC

*** This bug has been marked as a duplicate of 155538 ***

Comment 18 Michael A. Peters 2005-09-24 21:45:17 UTC
I think this actually was a dup of Bug #166702 (termcap) and not Bug #155538
The new package from #166702 has completely resolved the issue for me on fc4.

Comment 19 Fedora Update System 2005-11-07 19:33:25 UTC
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 20 Fedora Update System 2005-11-14 18:04:11 UTC
From User-Agent: XML-RPC

xterm-205-1.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.


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