GNOME Bugzilla – Bug 305507
vte fails to recognize valid escape sequences
Last modified: 2007-01-25 01:53:25 UTC
Version details: 3-1 Distribution/Version: Fedora3 Fedora 3 system: After update of vte from 0.11.11-6 to 0.11.13-1.fc3 gnome-terminal (fedora 3 gnome-terminal-2.7.3-1) users with 'modified' PS1 variables noticed extra characters in prompt. Steps to reproduce on Fedora3 using gnome-terminal-2.7.3-1 1) Update to vte-0.11.13-1.fc3 2) Set PS1 to '\[\033[0;1m\][${PWD}]\[\033[0;m\]$ ' 3) Start a gnome terminal. Expected additional prompt characters will not be seen. vte 0.11.11-6 displayed [/home/username]$ vte 0.11.13-1.fc3 displayed [/home/username]^[[0;m$ Additional info: vte bug detailed in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158716 vte maintainer requested that this problem be reported to this bugzilla with the comment that it is a "regression from that earlier version of vte".
Hi Barry (thanks for the report), I can confirm this problem. I believe it was this change: 2004-11-16 nalin * src/table.c(_vte_table_addi): expand "%m" locally so that we can distinguish between control sequences which differ only in the number of numeric arguments they expect. This means we have a new upper limit on the length of a numeric argument list we'll recognize. Which makes us fail sequences like [0;m] since we only allow [0m] or [0;0m] to be matched. Note that http://vt100.net/docs/vt220-rm/chapter4.html#S4.9 specifies that you shouldn't use any delimiter if you use a single parameter. But given that this works in xterm (and that this table parsing change might affect other sequences) it should be fixed. I'll try to look into it (Also moving it to vte where it belongs)
Created attachment 47645 [details] [review] Adds CSI %d;m to the capabilities This is a simple patch that fixes it.
Created attachment 47646 [details] [review] Fixes the matching in case of a single parameter _and_ the delimiter ; Here's a more generic fix that makes _vte_table_addi match a single parameter even when the delimiter is included. This is a more general low-impact fix for this (and maybe other related problems). So we don't need to tweak the capabilities for every %m (multiple match) encountered.
*** Bug 308970 has been marked as a duplicate of this bug. ***
Here's an updated patch that fixes #308970 and this bug. Basically when encountering %m we used to match only strings like "{number};{number};{number}<value>" Now we also match (which look like valid sequences according to http://vt100.net/docs/vt100-ug/chapter3.html#S3.3.2) : ";{number};{number};...<value>" "{number};<value>" ";<value>" NOT to be applied on HEAD yet as I'd like to test some more things and fix more escaping problems while I'm at it
Created attachment 48647 [details] [review] Fixes a bunch of escape sequence bugs
Here's an updated patch. Marc, this patch fixes almost all of your attachment (http://bugzilla.gnome.org/attachment.cgi?id=48567&action=view) The only thing not recognized still is some quite odd sequence: ESC [?25I I found no mention in the vt* docs about this one, so I'll dig up xterm sources to verify things. Since the attachment ends with the following sequences: ..ESC[?25IESC[19;51HESC[24;1HESC[?1lESC[?25h I also suspect it could be a typo and it really meant ESC[?25l, which would make the cursor invisible, since at the end there is ESC[?25h which makes it visible again. Anyways, if I learn that xterm ignores such a signal I'll close this, otherwise I'll see if I can fix this last bit.
Created attachment 48803 [details] [review] Almost completed this specific escape sequence bug
*** Bug 304324 has been marked as a duplicate of this bug. ***
Traced down what xterm does on 033 [ ? 25 I (i.e 1B 5B 3F 32 35 49): parse 001B -> 5 ansi_table parse 005B -> 53 esc_table parse 003F -> 18 csi_table parse 0032 -> 16 dec_table parse 0035 -> 16 dec_table parse 0049 -> 0 dec_table CASE_GROUND_STATE - exit ignore mode Which in xterm resets the parser to the ground (i.e. initial) state. http://vt100.net/emu/dec_ansi_parser
*** This bug has been marked as a duplicate of 400072 ***