Bug 13281 - backspace in vi inserts ^?
backspace in vi inserts ^?
Status: CLOSED DUPLICATE of bug 11294
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2000-06-30 14:05 EDT by Wil Harris
Modified: 2014-03-16 22:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-18 14:24:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Wil Harris 2000-06-30 14:05:00 EDT
When editing files after upgrading from 6.2 to beta 2 vi does not behave
properly. Backspace will insert a ^?. By using the delete key I can delete
characters in front of the cursor. This happens both in insert mode and
when trying to perform a search (/<text>).
Comment 1 Bernhard Rosenkraenzer 2000-07-18 14:24:18 EDT
I can reproduce this only when running in screen as root... Seems to be a screen
problem (or a problem with the screen termcap entry?).
Comment 2 Bill Nottingham 2000-07-21 10:24:27 EDT

*** This bug has been marked as a duplicate of 11294 ***
Comment 3 David Balažic 2000-07-26 04:04:49 EDT
It seems that the terminfo/termcap entry for 'screen' says
that 'kbs' is ^H. The man page for screen also says that
screen will convert the 'kbs' char of the "real" ( "physical" )
terminal to ^H. But when I run screen on VT1 it translates
'kbs' ( which is ^? on real VT1 ) to ^? in screen.
This causes problems with all programs that respect terminfo/termcap
and expect ^H.

More details ; the man page says that one of the default keybindings
is "bindkey -k kbs ^H" , but when I run screen and give it a
"bindkey" command, the 'kbs' binding is not listed; not in the default,
user or application listing.
I also tried the original screen sources and it behaves the same.
It is either a screen program bug or a bug in the documentation
( and in the terminfo entry ).

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