GNOME Bugzilla – Bug 566169
vte is printing (some) non-printable characters
Last modified: 2015-12-26 13:06:39 UTC
Please describe the problem: While defining my PS1 prompt to use some non-printable characters, vte-based applications (I tested with gnome-terminal and XFCE's Terminal) are printing characters that shouldn't be printed, the characters are, specifically, ESC-k and ESC-\. Those characters are needed if you want to set dynamic window titles in GNU screen (section 10.1.2 in screen's user's manual - http://sunsite.ualberta.ca/Documentation/Gnu/screen-3.9.4/html_chapter/screen_10.html). Notice that the behavior shown by gnome-terminal and XFCE's Terminal doesn't match xterm's and rxvt's behavior. Steps to reproduce: 1. Open a VTE-based application, gnome-terminal, for instance. 2. type: export PS1='\[\033k\033\\\] ' 3. See that your prompt is substituted by k instead of nothing 4. Open xterm, repeat step 2. and see that it is going to work as expected Actual results: You see k when you should see nothing as your prompt Expected results: Does this happen every time? Yep. Other information: Distribution: Slackware Slackware 12.2.0 Gnome Release: 2.24.2 2008-11-26 (Dropline GNOME) BugBuddy Version: 2.24.2 System: Linux 2.6.27.7-smp #2 SMP Thu Nov 20 22:32:43 CST 2008 i686 X Vendor: The X.Org Foundation X Vendor Release: 10402000 Selinux: No Accessibility: Disabled GTK+ Theme: TwoEighteen Icon Theme: Gion
Created attachment 125586 [details] Screenshot showing the behavior present in gnome-terminal, Terminal, rxvt and xterm
ESC k is not a recognized escape sequence by xterm either, see http://invisible-island.net/xterm/ctlseqs/ctlseqs.html . It's a custom sequence made up by "screen", and you trying to use it outside of screen is an error on your side. You should make your prompt conditionally contain this only inside screen. That being said, indeed xterm does a better job than vte in ignoring unrecognized sequences, I recall vte's approach causing problems in other situations too. Fixing this would require to rewrite the matching engine (a large amount of work), or to manually adding entries for all unhandled sequences (which is error-prone and painful to maintain). Anyway, this should remain on our TODO list.
So let's dup this to 403130. *** This bug has been marked as a duplicate of bug 403130 ***