Backspace key in GNU Screen not detected correctly

[Chris Peterman]

In rxvt-unicode and xfce4-terminal (so far) you have to manually set the backspace key to Control-H in preferences. It only seems to affect screen however. This bug may lie elsewhere but I just wanted to get it out

[Micah Cowan (micahcowan)]

I can't confirm this on Feisty. Is this still an issue for you?

[Johannes Kastl (ubuntu-launchpad-ojkastl)]

I can confirm this on two machines running Xubuntu feisty.

[Micah Cowan (micahcowan)]

Couldn't confirm in rxvt-unicode, but can confirm for xfce4-terminal. My xfce4-terminal sends ^? (ASCII DEL) for backspace, and claims to be xterm, but under screen, the backspaces become ^@ (ASCII NUL). I'm not sure what is causing this, as it works fine under gnome-terminal and (for me) rxvt-unicode, both of which are also using ^?, and gnome-terminal claims to be xterm.

It may be that xfce4-terminal isn't as compatible with xterm as it claims to be.

If you are still experiencing issues with rxvt-unicode as well, what version of that package do you have installed?

[Micah Cowan (micahcowan)]

I asked a friend, who is running Xubuntu feisty, to verify the behavior, and found that he did not have this problem when he was running an older version of screen (via an ssh session to another, Mandrake-based box). I can't think of any way that the fact ssh was involved could effect the behavior, so I'm guessing that it works with the older version of screen. Would be worth verifying that (a) it works as expected in some older version of screen (the version in this case would be 3.09.13), and (b) it is broken with latest upstream (IOW, not an Ubuntu-specific breakage).

[Micah Cowan (micahcowan)]

Something to think about: vim sets various terminal settings via tcsetattr, and also sends various "start mode X" (for instance, keypad transmit mode) sequences. It's possible that one of these triggers the odd behavior in screen/xfce4-terminal. Worth looking into. Screen may also be triggering the bug in xfce4-terminal in a similar way. Need to trace a few processes, especially to determine whether screen itself is receiving ^@ characters from the delete key, or if it is receiving ^? and transforming it into ^@. One possible way to check for the latter might be to have a multi-session with an xfce4-terminal and a different terminal (such as gnome-terminal) viewing the same terminal session: if gnome-terminal sees ^? while xfce4-terminal sees ^@, when typing <delete> from within xfce4-terminal, then we know that the transformation is occurring within screen.

[Luke Hoersten (lukehoersten)]

I can confirm this on Feisty with Screen version 4.00.03 (FAU) 23-Oct-06, GNU bash version 3.2.13(1)-release (i486-pc-linux-gnu), and GNOME gnome-terminal 2.18.0.

In screen with gnome-term:
1) with emacs: ASCII delete, ctrl+h, and esc sequence don't work.
2) with irssi: only ctrl+h works.
3) with bash shell: only ctrl+h works.

Same symptoms in xterm + screen with emacs and irssi.

Whey I say "doesn't work," I mean no backspace is produced and a "Wuff ---- Wuff!!" is displayed by screen.

This however *WAS NOT* a symptom on my mac book laptop. Only my desktop. Both with Feisty.

[Luke Hoersten (lukehoersten)]

Turns out I was exporting TERM=xterm-color because the case statement looks for it in the stock ~/.bashrc, to get color. I realized below that there is another PS1 outside the case statement which can be uncommented to add color. When I commented my TERM=xterm-color and got color through the color PS1 (not through the case statement),

Conclusion: changing term types caused this problem for me. The ~/.bashrc xterm-color case statement was a bit misleading for me.

[Micah Cowan (micahcowan)]

My term wasn't set to xterm-color, IIRC; and also, still seems likely to be a bug: even if the TERM setting is wrong, there's no obvious reason to me that screen should act like NULs are being sent when they aren't (or, if such is the case, that the terminal should send NULs to screen).

[RedLoach (redloach)]

Confirming on xubuntu (feisty), Screen version 4.00.03, and xfce4-terminal 0.2.6 (Xfce 4.4.0)

[Khem Raj (khem-raj)]

I am also seeing this problem when I login into my ubuntu edgy machine from macosx terminal program and use screen. Changing TERM to xterm helped but for other Linux distro it worked correctly with xterm-color

[Darren Davison (darren-davisononline)]

can confirm same behaviour in Gutsy Tribe5 (Xfce 4.4.1/xfce4-terminal 0.2.6/screen 4.00.03)

[Greek Ordono (grexk)]

same behaviour in Gutsy Final Release.

[Colby W. (yorokobi)]

From http://ubuntuforums.org/archive/index.php/t-90910.html

There seems to be several ways around this bug. Perhaps the best solution is to use

bindkey -d -k kb stuff "\010"

in $HOME/.screenrc

[Tomas Cassidy (tomas-cassidy)]

I can confirm that this bug still exists in Ubuntu 8.04. I am connecting to Ubuntu 8.04 Server via ssh and running screen. When I try to delete text with the backspace key, it prints the visual bell "Wuff Wuff!".

[Micah Cowan (micahcowan)]

Tracked upstream with https://savannah.gnu.org/bugs/index.php?23868

(Note that producing "Wuff Wuff!" is not enough to reproduce this bug: you need to verify, say by typing into the "cat" command, that you're actually getting ^@ characters for backspace: other problems with backspaces are more commonly a result with errors in your configuration or environment.)

[Micah Cowan (micahcowan)]

This happens in xfce4 when preferences for sending backspace is set to "autodetect". Not when an explicit value ^H or DELETE is set. Hm... seems likely to be an xfce4 or vte thing, then. Retargetting for xfce4-terminal.

For some annoying reason I can't for the life of me figure out (unless it's somehow related to the use of a second pty), I can't reproduce the problem within the "script" command.

I've been reproducing the problem by running "screen cat" and hitting the backspace a couple times to see if I get ^@.

In response to the bindkey solution: that won't work, since -k kb is ^?. The following works better:

  bindkey -d ^@ stuff ^?

[Gauvain Pocentek (gpocentek)]

Setting this bug as invalid for xfce4-terminal since it's just a config issue.
In the preferences dialog, Advanced tab, set the "Backspace key generates" to "ASCII DEL".

Feel free to reopen and assign to xubuntu-default-settings or other terminals that might have this problem.

[Micah Cowan (micahcowan)]

Retargeting at vte; All xfce4-terminal does is call vte_terminal_set_backspace_binding with VTE_ERASE_AUTO.

[Micah Cowan (micahcowan)]

Just because it's a config issue, does not mean it's not a bug. The bug (as explained in the original description) is that changing it away from autodetect is required.

Tracked down the source of the problem: vte will send whatever the terminal's erase character is, even when it's undefined (that is, '\0'); screen unsets erase and other keys. Vte ought to fall back on a reasonable value, rather than issue the obviously-wrong ^@. ^? seems like a good candidate...

Screen should probably leave the value alone as well. Will investigate why this is done, in the Savannah bug whose link was posted earlier.

[Micah Cowan (micahcowan)]

Note; the patch above includes literal control characters in the source, namely the ^? (DEL) character; it may not display properly, depending on what you use to view it. I find this practice distasteful, but the surrounding code included literal control characters as well, so I bowed to consistency.

[Micah Cowan (micahcowan)]

Setting to Confirmed per https://wiki.ubuntu.com/Bugs/HowToFix

[Sam Briesemeister (sam-briesemeister)]

I found a workaround per a comment above. I'm using gnome-terminal, and on some systems I use, 'screen' produces a beep/bell when I hit 'backspace'.

in ~/.screenrc:

bindkey -d ^? stuff ^H
bindkey -d ^@ stuff ^H

It now behaves as expected.

[Micah Cowan (micahcowan)]

That's a different problem, if it's the first line that's working for you.

A much better solution is to keep the backspace as ^?, and make sure "stty erase ^?" is set for the terminal (or that the terminal is otherwise set to send ^?). It makes a much better choice than ^H, which confuses some programs (notably Emacs).

[Sam Briesemeister (sam-briesemeister)]

Micah,

Thanks for pointing that out - I was noticing some unexpected behaviors, this explains them.

[Sam Briesemeister (sam-briesemeister)]

Also worth noting, this bug has been around for a while - why haven't I had issues with it until recently?

https://bugzilla.redhat.com/show_bug.cgi?id=11294#c13

Still no solution by me.

[Micah Cowan (micahcowan)]

That link is not the same issue; it has to do with the terminfo and stty disagreeing with eachother. Fixing either the terminfo or stty should fix the problem (they agree with each other in upstream screen AFAICT; they disagree in some packages).

This bug has to do with vte-based terminals, such as xfce4-terminal and TerminalScreenlet, sending ascii NUL (^@) for backspace when they are set to auto-detect what to send for backspace, which is a different issue. Other backspace problems are nearly always misconfigurations of the environment. They will always exist, because such misconfigurations will always occur easily.

[Sam Briesemeister (sam-briesemeister)]

I've dropped all the bindkey statements from my .screenrc, as they were causing other troubles when using other applications (e.g. vim), as predicted.

I'm now using an alias via .bashrc, so now all 'screen' is translated to 'screen -T $TERM'. This plays a lot nicer, and seems to produce the desired effect.

[James Westby (james-w)]

Hi,

I'm closing the xfce4-terminal task, as that uses vte, so if vte is fixed
xfce4-terminal will be fixed.

Thanks,

James

[Bryce Harrington (bryce)]

Sounds like just the vte patch needs sponsored, so closing the screen task. Feel free to reopen if something else needs investigated there (or maybe better to file a new bug).

[Launchpad Janitor (janitor)]

This bug was fixed in the package vte - 1:0.17.4-0ubuntu3

---------------
vte (1:0.17.4-0ubuntu3) jaunty; urgency=low

  * 94_no_nul_backspace.patch: Avoid sending NUL character for
    backspace, when the termios's erase character is undefined and
    backspace is bound to VTE_ERASE_AUTO. (LP: #29787)

 -- Micah Cowan <email address hidden> Thu, 17 Jul 2008 02:06:29 -0700

[Morten Kjeldgaard (mok0)]

I've been trying to figure out the screen/backspace problem tonight.

I ssh'ed into two different Linux boxes from my Mac, an Intrepid and a Lenny system. With screen_4.0.3-11 on both machines, it only worked correctly on the Lenny system. The /etc/screenrc file was identical on the two machines. In my experiments, I didn't use any ~/.screen file.

I could find no differences on the two systems wrt. terminal settings etc. ( Identical output from stty and infocmp -l). However, on the Intrepid system, I could get the correct behaviour from screen if I invoke screen like this:

$ TERM=screen screen

On the Debian system, I only need to do this:

$ screen

[Micah Cowan (micahcowan)]

Morten, is this the same "Wuff, Wuff" problem, which shows ^@ chars inside cat?

If so, the way to fix this is to turn off any "autodetection" settings for what backspace should send, and explicitly specify the code it should send (probably, ^?). You could also download the latest sources for screen via the git repository at Savannah, as we've fixed this on our end as well as submitting the vte patch.

If not, then you should file a new bug or ask for help on an appropriate forum (such as <email address hidden>).

[mathew (meta23)]

Just hit the same problem in intrepid: terminal set not to use ^H for backspace, for OS X compatibility, and reconnecting to a screen session resulted in backspace not working.

TERM=screen screen is a workable workaround for me.

[Micah Cowan (micahcowan)]

TERM=screen screen is _never_ good advice (unless you're running "screen -m" directly inside of a screen session). Also, if TERM=screen screen fixes your problem, then your problem had nothing to do with this bug, which is specifically that some terminals send ^@ screen, rather than the usual ^? or ^H.

Other backspace problems are nearly always a problem of incorrect terminfo descriptions for the parent terminal, or incorrect stty settings. Stty is the easiest to fix, so start with "stty erase ^?" and work from there.

[Ray (ray-redhat-bugs)]

Description of problem:
When using 'screen' from within an XFCE terminal, hitting backspace does nothing. From a vi session it seems that a '^@' or NUL is being sent instead of ^H or ^?. Workaround is to configure the XFCE Terminal to explicitly sent ^H or ^?, but Auto Detect should really do the "right thing" within screen.

Version-Release number of selected component (if applicable):
vte-0.17.4-1.fc10.i386

How reproducible:
So far, always.

Steps to Reproduce:
1. Start XFCE
2. Open an XFCE Terminal
3. Start screen (enter 'screen')
4. Type some text then try backspacing.

Actual results:
No backspace occurs.

Expected results:
Backspacing!

Additional info:
I'm not sure if this is VTE's fault (bugs from other distro's led me to believe it was), XFCE Terminal's or screen's

My TERM is set to xterm in XFCE Terminal before starting up screen. I have tried with vt100, tried starting screen with TERM=screen screen, and various .vimrc and .Xresources tricks to no avail.

I notice that if I ssh from the machine to somewhere else and start screen on the remote server, backspace works fine. Odd?

I have been able to reproduce this on multiple Fedora 10 installs with virgin configs. I tried older versions of screen (back to the one included in RHEL5).

[Rolf Leggewie (r0lf)]

I still see this on in an uptodate jaunty box. reopening.

[Jayson Williams (williams-jayson)]

I am seeing this same issue on Jaunty as well. TERM=screen screen does not resolve the issue. How do I remap the backspace key in screen to send ^H

[Jayson Williams (williams-jayson)]

Here is the best solution I have found. For Jaunty Ubuntu xterm, right-click on the terminal screen to bring up the terminal options. On the left panel, select Advanced. Chane the Backspace Key Generates selection from Auto-detect to Control-H. That works for an xterm. I am using a Screenlet terminal, so this does not work for me. I suspect that my Screenlet terminal is hard coded to autodetect the backspace key, with no options I have found to change it.
Hope this helps someone.

[Kenyon Ralph (kralph)]

On 2009-08-05T15:00:19-0000, Jayson Williams <email address hidden> wrote:
> Here is the best solution I have found. For Jaunty Ubuntu xterm,
> right-click on the terminal screen to bring up the terminal options.
> On the left panel, select Advanced. Chane the Backspace Key Generates
> selection from Auto-detect to Control-H. That works for an xterm. I am
> using a Screenlet terminal, so this does not work for me. I suspect
> that my Screenlet terminal is hard coded to autodetect the backspace
> key, with no options I have found to change it.

That is not for xterm. That sounds like it is for xfce4-terminal. xterm
is a different package and seems to be unrelated to this bug.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Nigel Babu (nigelbabu)]

Thank you for the patch and thanks for forwarding upstream. I have marked this patch as "patch-forwarded-upstream"