GNOME Bugzilla – Bug 403130
Vte should ignore escape sequences it doesn't know about
Last modified: 2018-03-27 17:45:10 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.
*** Bug 326554 has been marked as a duplicate of this bug. ***
Feel like cooking?
*** Bug 129940 has been marked as a duplicate of this bug. ***
Unknown OSC codes should be ignored too. (See also bug 722685 comment 6.)
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...
We build matcher on the fly IIRC? If it's fixed-table, we should look into using something like ragel.
*** Bug 744929 has been marked as a duplicate of this bug. ***
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.
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?
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 :)
> 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.
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
*** Bug 566169 has been marked as a duplicate of this bug. ***
Fixed on master.