Bug 13281 - backspace in vi inserts ^?
Summary: backspace in vi inserts ^?
Status: CLOSED DUPLICATE of bug 11294
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: screen   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-06-30 18:05 UTC by Wil Harris
Modified: 2017-05-21 18:44 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-18 18:24:20 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 Wil Harris 2000-06-30 18:05:00 UTC
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 18:24:18 UTC
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 14:24:27 UTC

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

Comment 3 David Balažic 2000-07-26 08:04:49 UTC
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 ).

Comment 4 openshift-github-bot 2017-05-21 18:44:43 UTC
Commit pushed to master at https://github.com/openshift/origin

Merge pull request #14158 from soltysh/issue13281

Merged by openshift-bot

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