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 332630 - Does not handle a particular escape sequence nor ignore escape sequences it doesn't know about
Does not handle a particular escape sequence nor ignore escape sequences it d...
Status: RESOLVED DUPLICATE of bug 400072
Product: vte
Classification: Core
Component: general
0.11.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-26 15:11 UTC by Loïc Minier
Modified: 2007-02-01 09:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Loïc Minier 2006-02-26 15:11:12 UTC
Hi,

When closing zile (an emacs-like editor) from a vte terminal, one sees:
stephen@jupiter:~$ zile
[?1036;lstephen@jupiter:~$

An escape sequence sent by zile to clean up the terminal isn't interpreted by vte, even if it claims TERM=xterm.

Thomas Dickey commented further:
<<
It's a VTE bug.  Whether gnome-terminal, etc., do anything useful with
the escape sequence is irrelevant since it is a well-formed control
sequence (so VTE has to be able to parse it, not get confused and let
characters echo onto the screen).  Echoing the sequence is incorrect.
>>

You can reproduce this problematic sequence with:
printf "\\033[?1036;l"

The point here is that even if it would be nice to support this particular escape sequence, it would be useful to completely ignore sequences that vte doesn't know about instead of displaying them.

This is Debian bug http://bugs.debian.org/337014.

FYI, zile's upstream workarounded this by sending another escape sequence to avoid this bug, so you won't see the bug with zile directly anymore.

Cheers,
Comment 1 Chris Wilson 2007-01-31 23:40:25 UTC

*** This bug has been marked as a duplicate of 400072 ***
Comment 2 Loïc Minier 2007-02-01 08:24:06 UTC
Chris, thanks for pointing at this newer bug; I've built vte from SVN and can confirm the escape sequence is not output anymore.

However, can you confirm that other escape sequences (even if not these are not supported by vte) do not result in spurious output?

I also wonder, is this particular escape sequence ("\\033[?1036;l") implemented or simply ignored?
Comment 3 Chris Wilson 2007-02-01 08:46:21 UTC
Alas, unknown escape sequences are still passed through. That escape sequence, 'ESC[?%ml', is now handled correctly since %m is used for matching (\d*;?)* - or at least should be ;)

I took this bug to focus on the problematic sequence which is a dup of the later discussion, I'll open a new bug for discussion of how to handle unknown escape sequences
Comment 4 Loïc Minier 2007-02-01 09:15:17 UTC
I'm fine with you reusing this bug which really described two problems in once ("Does not handle a particular escape sequence" and "Does not ignore escape sequences it doesn't know about").