GNOME Bugzilla – Bug 104154
setting terminal title causes text to appear in terminal
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: Steps to reproduce the problem: 1. 2. 3. Actual Results: Expected Results: How often does this happen? Additional Information:
Works fine here. Will need more info to reproduce. What's running in the terminal at the time, what version of the terminal do you have, how do you set the title (Set Title menu item?)
Sorry: bugzilla's simple bug input didn't seem to give me an option to modify the above. I'm not familiar with bugzilla, so I'm not sure if this is a bug or not. I use a utility called xttitle to set my terminal title. It used to work with gnome-terminal. It doesn't any more. I'm using gnome-terminal version 2.2.0 (but this bug has appeared with previous versions). When xttitle runs, something like this happens: daf@imp ~> xttitle abcdefghijklmnop daf@imp ~> ghijklmnop\ This happens regardless of the preference regarding whether setting the terminal title affects the window title. That is, if the preference specifies it, the window title will get updated, and if the the preference doesn't, it won't, if you follow me.
thanks, moving to terminal emulator. Can you give us a pointer to where we can download xttitle?
xttitle's in Debian (woody or later), or you can get it from http://www.jarvis.com/xttitle/
I can't reproduce this here (xttitle doesn't create any artifacts here), but the control sequences output by xttitle seem a bit odd. Specifically, it outputs: {OST}2;{requested-window-title}{BEL}{ST}{cursor-up}{newline} {OST}1;{requested-icon-title}{BEL}{ST}{cursor-up}{newline} {OST}21;{requested-window-title}{BEL}{ST}{cursor-up}{newline} {OST}2L;{requested-icon-title}{BEL}{ST}{cursor-up}{newline} The {cursor-up}{newline} pairs more or less cancel out, which leaves {OST}2;{requested-window-title}{BEL}{ST} {OST}1;{requested-icon-title}{BEL}{ST} {OST}21;{requested-window-title}{BEL}{ST} {OST}2L;{requested-icon-title}{BEL}{ST} The terminal properly ignores the {ST} at the end, so we are left with {OST}2;{requested-window-title}{BEL} {OST}1;{requested-icon-title}{BEL} {OST}21;{requested-window-title}{BEL} {OST}2L;{requested-icon-title}{BEL} Which sets text property 2 (window title) to the requested window title, 1 (icon title) to the requested icon title, 21 (I have no idea what this means, don't see it in the Xterm docs either) to the requested window title, and 2L (again, I can't find docs for this) to the requested icon title. The last two are ignored by the terminal. The terminal wasn't recognizing the version of the control sequence which is terminated by {ST}, and that has just been fixed in CVS.
I did some tests, and I can only reproduce this bug if the shell is bash . No problem with zsh.
That's confusing. I have no idea how which shell you're using could affect it. Are you invoking xttitle from a command prompt, via an alias, or in a shell initialization file?
I've only installed xttitle, because I've received a bug report : http://bugs.debian.org/178066 I run xttitle from the command line without any alias. Here is a scrennshot : http://marillat.free.fr/dists/gnome-terminal.png The first line is from zsh and the second from bash
Likewise, that's the reason I have a copy of it here. It turns out that the parser's tripping up because it doesn't recognize properties 21 and 2L. I can change the sources to recognize and ignore them, but I'd still like to know what they're supposed to do.
Then I really don't know. If you think this is a xttitle bug tell me, I'll reassign this bug to xttitle.
I guess that'd make sense. Please cc: me on that bug report in case it turns out that it's a documented control sequence somewhere. Thanks!
This bug is fixed