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 403130 - Vte should ignore escape sequences it doesn't know about
Vte should ignore escape sequences it doesn't know about
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.15.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[fixed:vteparser]
: 129940 326554 566169 744929 (view as bug list)
Depends on: vteparser
Blocks:
 
 
Reported: 2007-02-01 08:56 UTC by Chris Wilson
Modified: 2018-03-27 17:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chris Wilson 2007-02-01 08:56:00 UTC
+++ This bug was initially created as a clone of Bug #332630 +++

xterm does not print unrecognised control sequences, eg echo -en '\e#9'
Our default action is to pass them through to the display unaltered.
Comment 1 Chris Wilson 2007-02-06 12:49:14 UTC
*** Bug 326554 has been marked as a duplicate of this bug. ***
Comment 2 Behdad Esfahbod 2007-11-27 13:25:09 UTC
Feel like cooking?
Comment 3 Behdad Esfahbod 2007-11-28 12:07:47 UTC
*** Bug 129940 has been marked as a duplicate of this bug. ***
Comment 4 Egmont Koblinger 2014-01-22 17:13:30 UTC
Unknown OSC codes should be ignored too. (See also bug 722685 comment 6.)
Comment 5 Egmont Koblinger 2014-01-22 18:16:48 UTC
I was looking at fixing OSC. Unfortunately a catch-em-all >>OSC "%s" BEL<< doesn't work, since the lookup table is not linear and requires all the patterns to be mutually exclusive. Coming up with a set of patterns that matches everything enclosed by OSC and BEL that's not caught by any other pattern is practically impossible. The code in table.c and and vte.c:vte_terminal_process_incoming() is terribly complicated, I'm afraid to touch it.

My current idea is to have another lookup table for the sequences to be ignored. If the main lookup table gives "no match" then we'd consult the second, and if it matched (at least partially) then we'd know what to skip.

Or, actually this could be hidden in table.c, a table could actually be a linear sequence of tables. caps.c:_vte_xterm_capability_strings[] could have another field for "priority", 0 for the main patterns and 1 for the fallback ones.

I really don't feel like doing this :( Let's wait until this feeling disappears...
Comment 6 Behdad Esfahbod 2014-01-23 19:52:26 UTC
We build matcher on the fly IIRC?  If it's fixed-table, we should look into using something like ragel.
Comment 7 Egmont Koblinger 2015-02-22 11:27:00 UTC
*** Bug 744929 has been marked as a duplicate of this bug. ***
Comment 8 George Nachman 2015-02-23 06:43:42 UTC
My initial thought was that if this is so hard to do for OSC then you'd also have issues with PM, SOS, DCS, and APC. Upon testing, DCS foo ST produces no output.
Comment 9 Egmont Koblinger 2015-02-23 16:29:55 UTC
I've no clue what PM, SOS, DCS or APC means :D

Bit of looking at vte's code (caps.c) and on vt100.net: seems it's ESC P or 0x90 (actually U+0090 encoded in the input charset, right?).  We don't support these: we just print each character literally.

The original report was about \e#9.  Now my biggest question is: if we don't support a certain escape sequence, how can we recognize where it finishes?  I understand that OSCs follow a common pattern, seems it's the same for DCS and probably others too, but what are the rules outside of these worlds?
Comment 10 George Nachman 2015-02-23 18:58:54 UTC
PM, SOS, and APC aren't used any more AFAICT, but work like OSC. The best docs I could find to describe how a parser should work are here:
http://www.vt100.net/emu/dec_ansi_parser

xterm defines a few sequences that begin with DCS (ESC P or 0x90, as you note, but at least in xterm's implementation 8-bit controls are disabled when UTF-8 is enabled). The only really notable DCS sequence in xterm is DECRQSS. iTerm2 defines DCS 1000 tmux ST to enable the tmux integration, which I doubt vte will pick up any time soon, but would be nice to silently swallow.

Regardless, all these sequences (OSC, PM, SOS, APC, and DCS) are terminated by ST (ESC \, or 0x9c). xterm (and iTerm2, and many other terms) also accepts BEL because ESC \ is annoying in shell scripts. CAN and SUB also finish the sequence but it won't be executed.

When I do this in Gnome terminal on Ubuntu 14 I get no output:
printf '\ePblah\e\'
So something is parsing DCS strings correctly!

In the case of sequences like esc # 9 (which is not defined in the standard, so far as I can tell), the state diagram in the aforelinked URL would allow you to handle it:

Start in ground state
Read ESC (0x1b)
Enter escape state
Read # (0x23)
Collect 0x23 and enter escape intermediate state.
Read 9 (0x39)
Perform esc_dispatch and return to ground state.

From what I can tell VTE does not use a state machine, so this might be nontrivial; that said, fixing OSC would be a great start :)
Comment 11 Egmont Koblinger 2015-02-23 19:14:03 UTC
> When I do this in Gnome terminal on Ubuntu 14 I get no output:
> printf '\ePblah\e\'
> So something is parsing DCS strings correctly!

You're right, I tried with \a terminator which is not recognized.  I have no clue where the relevant code is, will have to check.

> From what I can tell VTE does not use a state machine, so this might be
> nontrivial

Yup this was my conclusion too :) It's nontrivial even for OSC.
Comment 12 Egmont Koblinger 2015-03-01 13:58:46 UTC
We'd need to solve this for single bytes too, e.g. ASCII 3, as found here:
https://bugzilla.xfce.org/show_bug.cgi?id=7284
Comment 13 Christian Persch 2015-12-26 13:06:39 UTC
*** Bug 566169 has been marked as a duplicate of this bug. ***
Comment 14 Christian Persch 2018-03-27 17:45:10 UTC
Fixed on master.