Bug 11294

Yah, this problem is getting up my goat too.
Screen by default starts bash.. and this problem isn't evident in bash because
the readline library recognises ^? and ^H as backspace characters, but in
ordinary cooked input (try backspacing over what you type in the "cat" command)
and in ncurses apps (try backspacing over your search pattern less's / command)
..it won't work :)
You could change screen's terminfo so kbs = ^?, but then terminals such vt100
that the windows telnet clients like would have similar problems in screen, and
I think I read somewhere that it was for these clients that the value was
changed to ^H in the first place. It seems to me like screen needs code to
translate between the physical terminal's kbs and it's own kbs.

This is annoying me, too.  Why can't screen just inherit kbs from the physical 
terminal?  That would be less correct than translating between them, but should 
be simple to implement and better than the current situation.

I'm not a big fan of the erase character changes in 6.2; suddenly I have to use 
stty erase, which I previously haven't had to do on any platform except HPUX.  
In addition to the screen problem, logging in from the terminal program I use 
under Windows (SecureCRT) also incorrectly gets ^H as the erase character.

Actually, it seems that the screen termcap does inherit kb from the attached 
terminal when a new console is created, but sets the erase character to ^H 
regardless.

I should note I am strongly opposed to translating DEL to ^H in screen, as I 
like to run emacs under screen; the other way around would make more sense.

*** Bug 13281 has been marked as a duplicate of this bug. ***

I don't understand how screen can simply inherit kbs? the terminfo database is
fixed, how can you have a variable backspace key?

I was under the impression screen sets erase to whatever the screen terminfo
entry says kbs is

Is there any reason why RedHat doesnt revert to the 6.1 and older behavior of
the backspace
key ?   It really annoys me that every time I telnet/rlogin/ssh to a non linux
system, be it
HP-UX, Solaris, AIX, NCR or whatever that backspace is always ^?
Is there a quick fix for this problem ?

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.

The 'Right Thing' is nasty and requires that I find character translation in
screen.
The dirty hack works now, and screen 3.9.6 is comming,
so well see if they fixed this in that.

Meantime, I used the fix suggested by david.balazic,
namely an hackish entry in /etc/screenrc

Closing, screen is now at 3.9.5-11

This change is worse than the previous state for people like myself who run
emacs under screen.  I've reverted the change to /etc/screenrc on my machine. 
Why not just change the erase character in the screen terminfo to DEL?

But resurrected in Fedora Core 2 ( screen-4.0.2-2.i386.rpm ).

I believe the 'Right Thing' is to change in file term.c line

- { "kb", T_STR  },
+ { "kb", T_STR  }, KMAPDEF("\010")

And the "bindkey -d -k kb stuff \010" can be removed from screenrc (
it already is removed in screen-4.0.2-2 )

Note, that I did not test the suggested change (yet).

(forgot to reopen the bug)

I tested the above patch and it works.

*** Bug 98752 has been marked as a duplicate of this bug. ***

Please don't do it this way. Either kbs is ^H in the terminfo entry
of the terminal (i.e. $TERM before you start screen) then this is a
noop, or it is ^? then you won't be able to send ^? anymore. Just
leave kbs alone.
Anyway please show me an application that looks at kbs? If you find
one (which I doubt) it is broken as it should check the stty setting
instead. I think you're trying to fix another problem with that gross
workaround.

I have already shown programs that don't work in there is a mismatch
between terminfo/kbs and the actual code sent. You show me a program
that does not work when terminfo matches reality.

I already did some test here :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77833#c9

I still don't see why we can't just use ^? under screen.

Because backspace is defined to be ^H under screen since ages. It is
like changing the ASCCI code of 'a' to 0x01. You can do it, and it
will even work on _your_ system, but it will break when coming in
touch with the rest of the world.

It already breaks when you come into contact with the rest of the
world, because most systems don't have a terminfo entry for screen. 
It seems to me that using ^H for kbs was a thinko at some point in the
distant past and we're all paying the price for it now.

^? has been the erase character on all sensible terminals for decades.
 Doing something different in screen doesn't make any sense.

I don't think that retaining this ancient brain damage is worth the
price of forcing workarounds in many other packages.

" because most systems don't have a terminfo entry for screen"
But they have "vt100", which is 90% comaptible ( includig kbs=^H ).

And a lot of existing terminals use ctrl-H.

I really don't see the problem of following the defined standards.

$TERM is set by the host for the benefit of the client, as explained
below. In the simplest case, it is set by the terminal for the benefit
of ls, pico, etc.

screen is both a client to your terminal and a host to your programs.
screen uses the $TERM set by your terminal (or terminal emulator) to
figure out how to display properly to that terminal, and figure out
the keys your terminal is sending to it. screen then sets $TERM for
its subordinate processes (ls, pico) so they know how to represent
their concept of the visual layout to screen, and how to interpret the
keys screen sends back to them.

gnome-terminal  <-->  screen  <--->  pico
             TERM=gnome    TERM=screen

For example:
 User hits Backspace.
 gnome-terminal sends \177 to screen.
 screen consults terminfo for "gnome", sees that \177 is kbs, and
interprets it as Backspace.
 screen sends ^H to pico.
 pico consults terminfo for "screen", sees that ^H is kbs, and
interprets it as Backspace.
 All is right in the world.

This intermediate translation (between what your terminal is sending
and what the client (pico) is receiving) is essential, as screen
allows you to "detach" and later "reattach" from a different terminal
(which may send different keys). In fact, you can use screen to
"multiplex", where multiple physical terminals can be attached to the
same screen simultaneously, all of which potentially using different keys.

screen defines a standard ^H to pass to subordinate processes, and
guarantees that those processes will always receive ^H to mean
Backspace, even in the face of changes in the physical terminal type.
screen uses ^H because vt100 uses ^H, and screen falls back to setting
$TERM to "vt100" if "screen" is not available.

screen sends ^H to its subordinate processes when it receives a
Backspace, so "infocmp -1 screen | grep kbs" should output:
        kbs=^H,
If it does not, this is a terminfo bug and should be re-filed under
ncurses. In rawhide, terminfo/screen does correctly list ^H.

To the best of my knowledge, gnome-terminal does send \177, so
"infocmp -1 gnome | grep kbs" should display kbs=\177. If it does not,
this is the bug (and should also be filed under ncurses). In rawhide,
terminfo/gnome lists kbs as \177.

If you can list a specific terminal (including its version), version
of screen, and version of ncurses, I can attempt to reproduce the
problem and figure out where the actual miscommunication or
mis-setting is. As of right now, I am unable to reproduce the problem
in today's rawhide versions of gnome-terminal (2.7.3-1), terminfo
(ncurses-5.4-11.fc3), screen (4.0.2-4), and cat (coreutils-5.2.1-19).

You can check your versions of these packages with:
rpm -q --whatprovides `which gnome-terminal` /usr/share/terminfo
`which screen` `which cat`

gnome-terminal is actually configurable. Under Edit, Current Profile,
Compatibility, Backspace key generates, if it is set to "ASCII DEL" it
will correspond to the terminfo/gnome setting of \177.

If I manually reconfigure gnome-terminal to use ^H instead of ASCII
DEL--without changing terminfo--then run cat and attempt to use
Backspace, I see "^H" appear on the terminal. This happens regardless
of whether I am using screen or not.

Please reopen if there is a specific combination that does not work.