Backspace key in GNU Screen not detected correctly

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

I can confirm this on two machines running Xubuntu feisty.

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?

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).

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.

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.

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.

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).

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

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

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

same behaviour in Gutsy Final Release.

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

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!".

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.)

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 ^?

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.

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

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.

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.

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

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.

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).

Micah,

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

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.

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.

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.

Hi,

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

Thanks,

James

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).

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

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

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>).

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.

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.

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

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

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.

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.

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