GNOME Bugzilla – Bug 543379
VTE sends NUL/^@ for backspace
Last modified: 2009-05-30 18:12:43 UTC
Please describe the problem: If VTE_ERASE_AUTO is specified for the backspace character binding, vte will use the erase character value from the termios' c_cc array, without first checking if it's undef (NUL). When running some programs, such as GNU screen, recent versions of which unset the erase character (and turn of -icanon), this results in sending ^@ as the backspace character, which is clearly never desirable. Steps to reproduce: Run recent (4.0.1+) versions of screen under xfce4-terminal, with the "Backspace generates..." set to Auto-detect. Alternatively, just run "stty erase undef", and then "cat", and type backspace into cat. Actual results: Backspace generates ^@ Expected results: Backspace should generate a sane character, probably ^? but perhaps ^H Does this happen every time? Yes Other information: Related bug reports, in Ubuntu Malone and Savannah (for Screen): https://bugs.launchpad.net/bugs/29787 https://savannah.gnu.org/bugs/index.php?23868
To be a bit more accurate, GNU screen sets the term's c_cc[VERASE] = _POSIX_VDISABLE.
Created attachment 114709 [details] [review] Patch against vte-0.16.14 Patch contains a literal control code, for consistency with the surrounding code.
*** Bug 541538 has been marked as a duplicate of this bug. ***
Can this patch please be reviewed? (Note to myself: Downstream Maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3071 )
...and it seems the patch was already committed in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/29787/comments/32
Can this patch please be reviewed?
What we do is exactly what xterm does. Fix screen. Or explain to me why this works in xterm but not vte.
Screen's side of the issue has already been fixed (in the development code, at any rate). However, I'm still convinced that this is undesirable behavior on the part of VTE. It may be that Xterm does as VTE. But in Xterm, the feature is named "backarrowKeyIsErase", which is quite straightforward; and since it's not a default, any user who explicitly sets this, and runs a program that unsets stty erase, probably gets what's coming. gnome-terminal and xfce-terminal both call this feature "Auto-detect", and VTE's docs itself say "attempt to determine the right value". This language to me strongly suggests that VTE wants to auto-detect an appropriate setting for the erase key, and obviously "undef" (nor ^@/NUL) is never an appropriate setting. Do as you wish, of course, but IMHO it's a defect.
I see your point. I'll add a VTE_ERASE_TTY for the current behavior and make auto do the right thing.
Does the patch actually work? It may in the case of screen, but with "stty erase undef", both of ^H and ^? are also printed on the screen. So, no sequence really "works". It's just about whether you get ^@ on the screen or ^?.
Do you mean that it gets sent to the screen instead of interpreted as backspace? I guess that could be... I suspect that some apps will still handle the ^? usefully: particularly when the terminfo entry has an explicit definition for kbs (ncurses apps, and screen, use this in preference over stty), but obviously that won't help when kbs=^H. So maybe it's simply a broken situation, and no app ought to undef erase if it expects to interpret it to begin with (it's not clear to me why screen had been changed in that way for 4.0.3). Though of course, typically stty is set to tell applications what the terminal's erase is, and not the other way around.
commit 33f265a9e3397126bd9f1b210c38bd54ea9a1ddb Author: Behdad Esfahbod <behdad@behdad.org> Date: Sat May 30 14:04:42 2009 -0400 Bug 543379 – VTE sends NUL/^@ for backspace Add VTE_ERASE_TTY. Also make AUTO send \H if terminal erase is undefined.
Should I add an entry for VTE_ERASE_TTY to the combo boxes in the Compatilibity tab in the profile prefs in g-t ?
Makes sense, when there's a release number for this.