After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543379 - VTE sends NUL/^@ for backspace
VTE sends NUL/^@ for backspace
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.16.x
Other All
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 541538 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-07-17 06:37 UTC by Micah Cowan
Modified: 2009-05-30 18:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Patch against vte-0.16.14 (1.52 KB, patch)
2008-07-17 09:30 UTC, Micah Cowan
rejected Details | Review

Description Micah Cowan 2008-07-17 06:37:11 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
Comment 1 Micah Cowan 2008-07-17 09:22:20 UTC
To be a bit more accurate, GNU screen sets the term's c_cc[VERASE] = _POSIX_VDISABLE.
Comment 2 Micah Cowan 2008-07-17 09:30:20 UTC
Created attachment 114709 [details] [review]
Patch against vte-0.16.14

Patch contains a literal control code, for consistency with the surrounding code.
Comment 3 Saleem Abdulrasool 2009-01-09 02:36:25 UTC
*** Bug 541538 has been marked as a duplicate of this bug. ***
Comment 4 André Klapper 2009-01-21 14:54:26 UTC
Can this patch please be reviewed?

(Note to myself: Downstream Maemo bug: https://bugs.maemo.org/show_bug.cgi?id=3071 )
Comment 5 André Klapper 2009-01-21 14:59:42 UTC
...and it seems the patch was already committed in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/29787/comments/32
Comment 6 André Klapper 2009-05-25 14:43:16 UTC
Can this patch please be reviewed?
Comment 7 Behdad Esfahbod 2009-05-25 22:14:28 UTC
What we do is exactly what xterm does.  Fix screen.  Or explain to me why this works in xterm but not vte.
Comment 8 Micah Cowan 2009-05-26 17:44:27 UTC
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.
Comment 9 Behdad Esfahbod 2009-05-26 17:47:47 UTC
I see your point.  I'll add a VTE_ERASE_TTY for the current behavior and make auto do the right thing.
Comment 10 Behdad Esfahbod 2009-05-26 18:02:28 UTC
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 ^?.
Comment 11 Micah Cowan 2009-05-26 18:37:41 UTC
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.
Comment 12 Behdad Esfahbod 2009-05-30 18:05:32 UTC
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.

Comment 13 Christian Persch 2009-05-30 18:09:41 UTC
Should I add an entry for VTE_ERASE_TTY to the combo boxes in the Compatilibity tab in the profile prefs in g-t ?
Comment 14 Behdad Esfahbod 2009-05-30 18:12:43 UTC
Makes sense, when there's a release number for this.