Those set the 'static title' which is always overwritten by the 'dynamic title' (ie the one set from escape sequences).

Are you saying that there is no menu or command-line way to set the title?  This isn't the way g-t used to work.  Where are the "escape sequences" described in comment 1?

Try:

[rishi@freebook ~]$ python
Python 2.7.5 (default, Oct  8 2013, 12:19:40) 
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.write("\033]0;FOO\a")
>>> 

Or:
echo -ne "\033]0;FOO\a"
... from within a shell script.

Out of plain curiosity, may I ask why you are trying to set the title? Is it to indicate some long running foreground process? Like a text editor, maybe?

The question in the last comment makes me think that we're not talking about the same issue.    In any event, suppose I have several windows open, some local others running slogin sessions to remote hosts--the title tells me which is which without having to go to each one and look, say, at the prompt. If not, using alt-tab to switch windows is useless as your choice is simply a bunch of terminal icons all with the title "Terminal".   Things get more complicated if each windows has more than one tab open (e.g., I have a long compilation, or other run, running in one tab and a bash shell in the other).

I tried your echo command--it works, but so does xtermset.   It makes my remotelogin script more slightly complicated, since it xtermset should be run in the gnome terminal before I open the remote session (using slogin or bash -i)

I'm still confused:

1.  The behavior was basically that of xterm's -T option and was the g-t behavior until recently.

2.  What do all the set title and/or --title commands do in practical terms?


Thanks for your help

BTW, 3.11.x is still in development. You'll likely be happier using a stable release (3.10.x).

"Set title…" does not work in continuous as of about half an hour ago. Is this bug going to be fixed for 3.12? If not, I suggest removing the menuitem for the release as there's nothing more frustrating than one that doesn't work.

More to the point, I would like to know so that I know whether to temporarily remove this from the user docs for this release.

(In reply to comment #6)
> "Set title…" does not work in continuous as of about half an hour ago. Is this
> bug going to be fixed for 3.12? If not, I suggest removing the menuitem for the
> release as there's nothing more frustrating than one that doesn't work.
> 
> More to the point, I would like to know so that I know whether to temporarily
> remove this from the user docs for this release.

I'm convinced that this is a bug--to have to use escape sequences or an external program makes no sense!   I'd leave the docs alone and get the developers to fix this.

Created attachment 274151 [details] [review]
quick ugly hack to restore functionality of the "Set Title..." dialog

I suppose the code that previously made the "Set Title..." dialog work got ripped out in https://git.gnome.org/browse/gnome-terminal/commit/?id=f27bf0135a2d18ba22158d28bf1f8c5f6ec066c8

(In reply to comment #7)
> (In reply to comment #6)
> > "Set title…" does not work in continuous as of about half an hour ago. Is this
> > bug going to be fixed for 3.12? If not, I suggest removing the menuitem for the
> > release as there's nothing more frustrating than one that doesn't work.
> > 
> > More to the point, I would like to know so that I know whether to temporarily
> > remove this from the user docs for this release.
> 
> I'm convinced that this is a bug--to have to use escape sequences or an
> external program makes no sense!

In comment 2 you were looking for a way to set the title from the command line. The escape sequence lets you do that.

Documentation stubbed in the gnome-3-12 branch, please ping the documentation team if there are any changes either in the 3.12 branch or on master.

*** Bug 706781 has been marked as a duplicate of this bug. ***

*** Bug 728148 has been marked as a duplicate of this bug. ***

The patch in comment 8 works.

Thanks

Actually, I spoke too quickly in comment 13.   The patch fixes the window title but still leaves tabs unlabeled.

I didn't realise tabs were still a feature since there's no longer any menu option to open a new tab.

(In reply to comment #15)
> I didn't realise tabs were still a feature since there's no longer any menu
> option to open a new tab.

There is. There is a setting to control what "open terminal" does, and irrespective of that ctrl+shift+t continues to open tabs.

I didn't realized tabs were no longer a promoted feature as I only use the shortcut and rarely open the menu.

Using the escape sequence now is the one and only way to set the terminal title (to sth else than the default "Terminal"), closing.

(In reply to comment #17)
> I didn't realized tabs were no longer a promoted feature

Sorry, but that is not true.

If escape sequences are now the only way to change the title (BTW 'xtermset -T title' works for both the tabs and window titles), then take the "Set Title" option out of the Terminal menu.   Nontheless, I'd like the decision to eliminate this feature reconsidered.

And I was wondering why were my tabs absolutely blank and why "set title" wouldn't actually set the title of my tabs. Please, this is not a new feature, it is a regression. I cannot send such a regression to ours users...

Why not check git master before complaining? This is all fixed. The escape sequence sets the title, if the title is unset or empty, it shows "Terminal", and the nonworking menu entry has been removed.

Unfortunately those commits are not in 3.12 branch so I cherry-picked them (probably missing a few) in updated our packaging as found in [1]. Thanks.

[1] http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=commit;h=a2b962b085fbca81ebc0b7ef5f448b233e165956

Maybe would be interesting to cherry pick these patches to 3.12 branch if a newer 3.12.x release is planned :/

Thanks

No UI changes on stable, sorry.

*** Bug 729206 has been marked as a duplicate of this bug. ***

I don't understand why this is NOTABUG.

Surely if removing the ability to set titles is intentional then the menu option should still be removed.

If the inability to set titles is unintentional that needs fixing.

I can understand WONTFIX for 3.12.x but NOTABUG seems wrong whichever approach is taken.

Set tab title is a very valid use-case in my opinion.

When working with multiple tabs it's useful to identify what the tab is intended to.
Removing this function is a bad choice.

WONTFIX for 3.12.x makes sense. NOTABUG doesn't, because it IS a bug.

Created attachment 277490 [details]
screenshot of Set Title... *not* working as expected.

Tell me again how this isn't a bug?

There won't be any more 3.12.x releases, so the resolution for 3.12 is irrelevant. The resolution for master is NOTABUG because the bug doesn't apply there; I could also have used INVALID or OBSOLETE or whatever; it simply *does not matter*.

*** Bug 732646 has been marked as a duplicate of this bug. ***

Christian - I'm staring at this menu item that says "set a title.." why is it there at all if escape sequences are the only way to set the title?  The bug then is that "Set title..." shouldn't exist.

People are frustrated because you're not being very clear on what exactly is the intent.  Mixed signals.  You have in 3.12 terminal, a "set title" but then in this bug you're saying that is not supported.  

I can understand that setting the title through escape characters ala classic Unix makes the code base simpler as well, some shell scripts are overriding the title when run making the feature un-usable.  If that is indeed you're thinking then you should state so and remove the menu item as it is causing confusion.

Through your code, you're saying that you support "set title" from the gui because it exists.

Never mind that last comment, I see that you've fixed the menu item.

*** Bug 734047 has been marked as a duplicate of this bug. ***

It's a pity that this option is gone. I was using it to handle certain terminal special during startup, where I've used a custom title like "floatingterm" and let the window manager react upon it.

Anyway, "gnome-terminal --help-terminal-options" still lists the "--title" option:

% ag -C2 "Set the terminal title" src
src/terminal-options.c
1160-      G_OPTION_ARG_CALLBACK,
1161-      option_title_callback,
1162:      N_("Set the terminal title"),
1163-      N_("TITLE")
1164-    },

src/gterminal.vala
271-        N_("UUID") },
272-      { "title", 0, 0, OptionArg.STRING, ref title,
273:        N_("Set the terminal title"), N_("TITLE") },
274-      { "cwd", 0, 0, OptionArg.FILENAME, ref working_directory,
275-        N_("Set the working directory"), N_("DIRNAME") },

This is really an important feature that was removed.

As a developer I use terminal for most of things I do so I have tons of tabs open and it was very useful to have an ability to modify name of the tab right when something was happening in this particular terminal.

Imagine I have a huge project which is being built right now. How may I change a tab name then? Wait until build is finished and use escape sequence?

Please return this feature back - this is definitely a but that was intentionally introduced.

As far as I can tell this feature isn't coming back (at least as of version 3.14.2) and the "bugs" were fixed, in that set title option has been removed from the menus.

One workaround is to use Xfce's terminal emulator (I have version 0.4.6, which comes with Slackware).  Not only is all the old functionality there, but it has the "feature" of starting in the previous tab's directory (although I'm not sure that I like this behavior)

(In reply to comment #36)
> This is really an important feature that was removed.

I concur, so until Christian changes his mind, let's share tips and workarounds for the missing feature.

Here's a bash function (added to my ~/.bashrc) that will do what the old tab title did:

    function title()
    {
        export PROMPT_COMMAND="echo -ne '\033]0;$1\a'"
    }

$ title foo

will do the trick. Now the only problem is some programs will insist on setting the title themselves. Vim was a regular offend which I had to shut up using:

    set notitle

in ~/.vimrc. Other applications may need similar treatments (GNU Screen comes to mind, but I haven't looked).

HTH

Hi all,
first: I am a great fan of gnome-shell and use it at work as of recently. At home for longer already.

About the gnome-terminal, I use a lot of scripts where one launches a gnome-terminal with a title and the --command/-e option. They go to all sorts of different computers in my company, which keeps me from using echo_sequence/xtermset/etc. 

May I with this state, that the --title/-t option has its importance. 

Many thanks to the devel team

H.

P.S. right under the comment box it says RESOLVED NOTABUG. I  can't see hwo this is not a bug :-)

I just installed Fedora 21 that installed Gnome Terminal 3.14.2 and the echo trick doesn't work, it does *not* change the window title nor any tab titles. And xtermset doesn't seem to exist anymore on Fedora 21.

Please do NOT share such misguided 'tips' as in comment 38. You should never override the PROMPT_COMMAND exported from vte.sh .

(In reply to comment #41)
> Please do NOT share such misguided 'tips' as in comment 38. You should never
> override the PROMPT_COMMAND exported from vte.sh .

Then pray do tell what the proper way of doing this is. Because if I just echo the escape sequence, bash execute PROMPT_COMMAND (__vte_prompt_command) which wipes whatever I had just put in the tab title.

As far as I can see, __vte_prompt_command() just prints the cwd and various other info, I hardly see anything life-threatening in there.

Argh, of course, the reason it doesn't seem to work is exactly because of that PROMPT_COMMAND discussion: it changes it back immediately after executing the echo, that's why I wasn't seeing anything.

Anyway, if you can't override the PROMPT_COMMAND either than how the heck *are* you supposed to set the title of your terminals the way you want it?

(In reply to comment #42)
> As far as I can see, __vte_prompt_command() just prints the cwd and various
> other info, I hardly see anything life-threatening in there.

The other info in the prompt-command (the \033]7;...\a escape) is how vte implements "stay in this directory when opening a new tab" (and presumably vte might add additional features in future that also rely on the prompt-command). Redefining PROMPT_COMMAND breaks that feature, so it is not supported.

In bash, putting an \033]0;...\a escape in PS1 would take precedence over PROMPT_COMMAND, and set the title without interfering with the \033]7;...\a escape.

I can understand why Christian wouldn't want "terminal title" to be a supported configuration option: the existence of the \033]0;...\a escape means that, as long as that feature is supported (and used by e.g. vim and screen), the configuration option can never be reliable, because the title set by that option can and will be overridden by processes running in the terminal.

(In reply to comment #36)
> Imagine I have a huge project which is being built right now. How may I change
> a tab name then?

Unix shells can typically put jobs in the background via ^Z and resume them with fg or bg. If yours can't, I suggest bash or zsh.

*** Bug 734968 has been marked as a duplicate of this bug. ***

Is it possible to reopen this issue a a design decision bug?

I have trouble accepting the reasoning behind tying the tab title to the "dynamic title" as set by the shell.  The tabs should be user-centric, not shell-process-centric.

I consider the tabs to be *GUI elements* that help organize my workspace.  I will have a tab for each activity.  A typical configuration: 

- three server tabs, each with a root login to a server

- six application tabs, each with a screen session, which in turn has separate windows for a terminal session, an editor, an interactive interpreter (e.g. python), a web application process and its output, and a database console

- a couple tabs open for my local workstation.


I need the tabs to tell me what high-level activity it hosts with a short, descriptive title, so I can go directly to "server X" or "application B".


Proposed change:  continue the current dynamic title behavior, unless a title is set by the user explicitly.  Thereafter, never change the title dynamically.

*** Bug 748466 has been marked as a duplicate of this bug. ***

It is a bug. With seven (!) duplicates. Users need this functionality.
Why you broke and remove functionality, that exist for years? 
Because of new-edge stupid programmers? Because of what?  What is next?

I'm completely disappointed. 
I switched and recommend other users to switch to the best GNOME version - 2.32 - to MATE Desktop Environment. 
Enough  GNOME 3!

(In reply to icewater from comment #46)
> Is it possible to reopen this issue a a design decision bug?
> 
> I have trouble accepting the reasoning behind tying the tab title to the
> "dynamic title" as set by the shell.  The tabs should be user-centric, not
> shell-process-centric.
> 
> I consider the tabs to be *GUI elements* that help organize my workspace.  I
> will have a tab for each activity.  A typical configuration: 
> 
> - three server tabs, each with a root login to a server
> 
> - six application tabs, each with a screen session, which in turn has
> separate windows for a terminal session, an editor, an interactive
> interpreter (e.g. python), a web application process and its output, and a
> database console
> 
> - a couple tabs open for my local workstation.
> 
> 
> I need the tabs to tell me what high-level activity it hosts with a short,
> descriptive title, so I can go directly to "server X" or "application B".
> 
> 
> Proposed change:  continue the current dynamic title behavior, unless a
> title is set by the user explicitly.  Thereafter, never change the title
> dynamically.

How do I vote for this?

I think we should reopen it, it is a bug, many bugs was duplicated with this bug, this functionality is important.

In old version, with the following one command:
gnome-terminal --tab -t "project1" --tab -t "project2" --tab -t "project3" --tab -t "LAB1" --tab -t "LAB2" --tab -t "LAB3"

I can create six tab once, each tab has a proper tile. Using other option, such as "--working-directory". I can open a developer environment with one command!!!!!!! it's very wonderful.

The "--title" is very useful, especially with multiple tabs, users need a custom static title.

To Øyvind:
>> Vote for this? 
When this functionality was removed, did someone vote for it?

Today installed ubuntu 15.04, found that gnome-terminal versin is 3.14
Cannot set title by -t option or --title option.

So I added a user-defined title option in a private patch.
Feature:
(1) Using -T option to set a user-defined title, it never changes.
(2) it ignores the close button in the tab with user-defined title.
    you can close it with right click.

Usage:
  -T, --ud-title=UDTITLE          Set the user-defined title, never change!

Example:
gnome-terminal --tab -T "aaa" --tab -T "bbb" --tab -T "ccc"


Refer: https://bugzilla.gnome.org/show_bug.cgi?id=748989

The design principle here is simple: the tab/window title is controlled by the terminal application. That's exactly as it is in other applications, e.g. with web browsers, where the title is set by the web site in the tab/window.

So the escape sequences emited by the terminal application are the right and only way to set the title.

> The design principle here is simple: the tab/window title is controlled by the terminal application.

Christian,

You obviously know more than us. Fine. *Teach* us how to get the feature back using whatever proper method you recommend. The fact that this bug has been active for 1.5 years should be a *clue* that something is wrong. The fact that you've been telling us "use escape sequences" _4_ times (I counted), yet no one seem to be able to figure out how to do so should be another clue that something is wrong.

The method I posted in comment #38 worked fine for a while but no longer does. I don't know if it's because of gnome-terminal 3.16 or a new version of bash. For now I just don't have the will to figure it out. It still works fine for my Debian Jessie (3.14) system at work.

Wrt comment #41, I'll just point out that your precious vte.sh is not sourced on Debian/Ubuntu systems. So whatever magic is enabled by this script is not available on those systems (a much more popular target than my niche Gentoo install).

So give us a hand, help us get back the feature some of us have used daily for the better part of a decade and let's just move on to other bugs/issues.

TIA

Christian,

For me, I don't want change the "web browsers" tab title, but I really need to changed the "terminal" tab title.

People often close tabs in "web browsers", but for terminal applications, there are some important history output information, I  never close them in my work, unless having to reboot OS. (You may say that there are some "screen applications", but "gnome-terminal" has its merit.)

The fact is, if there are several tabs, it's hard to distinguish them, I want to find out which one is the right LAB server/DEV server/tool/source code/or others.

I'm not sure the web browser window title example holds up.  A web page is single, fairly static document and a single meaningful title is all you need to identify a web page window/tab.  

The activity that takes place in a terminal window can be much more dynamic - and yet all the activity therein usually relates to a single task by which the human user recognizes it.  The many different activities that take place inside that window have no notion of each other, or the intentions of the user.

I might offer a spreadsheet as a counter-example.  Although I don't use spreadsheets often, if there are ever two or more sheets in the file, I will want to name them so I can distinguish which is which.   I don't want my spreadsheet software to update the tab name based on something going on *inside* the spreadsheet.  I don't want to use a function inside the spreadsheet to provide the name of the tab, especially when that function is prone to changing frequently based on how I'm currently using the spreadsheet.

And, honestly, the idea that setting the title of a GUI tab from within whatever session happens to be active within that terminal window is "the right and only way" is not supportable.  I respect Chris's opinion on how it should be done but that's just not true.

I do support GNOME's efforts to streamline and remove complexity, and on the whole I am extremely pleased and grateful for these efforts.  But the removal of this feature makes gnome-terminal less useful, and burdens the user with with a more intricate, error-prone, and unreliable process to get that very useful functionality back. 

Ultimately, I'm not the one writing code so I recognize my opinion does not have much weight in the physical world to back it up.  Still, I would like to know how the GNOME design process actually works.  Would I find the history that led to this decision in a developer's email list?

If the terminal application (I take that to mean the shell?) is the one that should control the terminal tab title, then we have lost functionality: keyboard shortcuts go to gnome-terminal, not to the shell, so there is no longer any way to set up a keyboard shortcut to set the tab title. It isn't the end of the world, but I kind of saw the point of gnome-terminal as being the thing to create and manage tabs, and in my mind "manage" includes setting titles, reordering, etc.

On the other hand, allowing the terminal itself to control the title is undeniably useful. I would suggest that there ought to be two separate properties here: the terminal's title and the managed tab's title. And gnome-terminal would decide how to combine those to produce the final displayed title. It can ignore one or the other, concatenate them together in either order, or fall back on defaults like "Terminal".

Why is this "RESOLVED NOTABUG"? The feature is really essential for any productive work.

An easy "workaround" to reimplement this feature is:

apt-get remove gnome-terminal
apt-get install konsole


It removes broken gnome-terminal with previously working but now missing functionality and installs KDE's terminal (works fine in Gnome or Unity environments).

In KDE's konsole, you can simply change tab's title by double clicking on it (or right clicking -> rename tab).

Created attachment 314364 [details]
tabs: comparison with design decisions in KDE's konsole

Just to compare with gnome-terminal, "design principles" in KDE's konsole are also really simple and help you focus on your work, not make it harder:

- user can rename the tab to an arbitrary string by double clicking (or right clicking -> Rename tab)

- there is visual feedback for events in inactive tabs (look at "old environment - master" and "events" tabs - their names changed colour, to indicate that some extra text appeared there)

Hi Egmont, Christian,

Is there some other plan to allow user to use a user-defined title?

In the latest version, you added "tabs menu" and "add tab" button, I think you also pay attention to multiple tabs. 
So why not support this useful and important feature? After all, it works well before.

I think this feature should not only come back, but also be enhanced, such as "double clicking -> rename", or allow user to define color for tab etc.

BTW: if you use Numix theme, "tabs menu" button looks bad.

Very frustrating attitude from gnome developers here, who REMOVED functionality that has been there for a long time, and that meny people, including myself, relies upon. Makes me wonder about the future for the gnome project, if this is representative for the project.
I'm just a user, what do I know? But at least I have been a user for a long time, and when a new release makes things stop working it really should need a VERY, VERY good reason. Which I can't see here.
Also, must users will not find out why this has stopped working. Most users don't file bug reports or search for these things. They just complain, and next time they probably choose some other terminal emulator that just works.

Created attachment 314367 [details]
with --tab, one command, open multiple tabs, but if no user-defined title, it's hard to get the right tab

By using --tab and -T option,

(In reply to Christian Persch from comment #52)

> The design principle here is simple: the tab/window title is controlled by
> the terminal application. That's exactly as it is in other applications,
> e.g. with web browsers, where the title is set by the web site in the
> tab/window.

Allow me to disagree and vote for bringing back this option.

Other apps, e.g. web browsers, document editors etc. display inner content that does have an explicit title or an inherent property (e.g. filename) that they can show, and users will end up with different titles for each tab with no extra effort. This is not the case with terminals. And we don't even support showing the running process's name in the tab. So unless users come up with extra hacks (wrappers in front of pretty much every application they're using) most of the tabs will have the same meaningless title.

Also, this feature is requested by many users. We should listen to our users and address their most common needs (and BTW bring back the word-char UI for the same reason). After spending so much time on vte/g-t, I wouldn't like users to migrate away to other terminals because this common and useful feature is missing from g-t.

(In reply to luozy from comment #59)

> I think this feature should not only come back, but also be enhanced, such
> as "double clicking -> rename", or allow user to define color for tab etc.

iTerm can do colors and it really looks nice. I'll try to get used to this feature to see how much I like it, but once you get used to it I guess it's damn useful :)

Created attachment 314418 [details]
iTerm colored tabs screenshot

Created attachment 314419 [details]
iTerm right-click menu on a tab label screenshot

An example of where this is causing me trouble, and I don't entirely understand why, is that when I open up a terminal, then ssh to another machine, I can no longer set the title. I echo out the escape code, and strace on the ssh process seems to show that it is being sent back, but something eats it before it can affect the title.

Of course, even if it worked it would be a nuisance, because locally I have an alias set up to send the right escape codes. When I'm ssh'ing, I'm typically going somewhere that does not have such an alias so I have to remember the right escape sequence myself. Having a hotkey sequence for setting the title was much, much nicer.

I guess I'll try out some other terminal program options.

I have in the meantime switched to terminator, but it does not look as
good / integrate as well as gnome-terminal.  But it is at least mostly
functional for renaming tabs.

Still on the cc: for this bug in hopes that a decision favorable to my
wants is made, eventually.

(In reply to Steve Fink from comment #65)
> An example of where this is causing me trouble, and I don't entirely
> understand why, is that when I open up a terminal, then ssh to another
> machine, I can no longer set the title.

There's no way ssh could corrupt this escape sequence. What I believe happens is that the title is changed, and your shell prompt (PS1 or PROMPT_COMMAND) immediately reverts it. Try

echo -ne '\e]7;newtitle\a'; sleep 2

to make sure that this happens.

(In reply to Egmont Koblinger from comment #67)
> (In reply to Steve Fink from comment #65)
> > An example of where this is causing me trouble, and I don't entirely
> > understand why, is that when I open up a terminal, then ssh to another
> > machine, I can no longer set the title.
> 
> There's no way ssh could corrupt this escape sequence. What I believe
> happens is that the title is changed, and your shell prompt (PS1 or
> PROMPT_COMMAND) immediately reverts it. Try
> 
> echo -ne '\e]7;newtitle\a'; sleep 2

Nope. No effect during or after the 2 second pause.

The last line in my ssh strace that has "newtitle" in it is:
write(6, "\r\n\33]7;newtitle\7\r\n\33]0;cltbld@dev-linux64-ec2-sphink:~\7[cltbld@dev-linux64-ec2-sphink.dev.releng.use1.mozilla.com ~]$ ", 116) = 116

I should note that I'm trying to switch to xfce4-terminal right now, though I'm having trouble creating a shortcut for setting the title (note to others: run xfce4-appearance-settings, select the Settings tab, make sure "Enable editable accelerators" is checked -- but for me, it still doesn't work for setting a shortcut for Terminal/Set Title....)

(In reply to icewater from comment #66)
> I have in the meantime switched to terminator

It's beyond the scope of this bugreport to come up with recommendations, but please be aware the terminator's stable release use a 4+ year old, gtk2-based vte as the actual terminal emulation widget, whereas gnome-terminal obviously uses the newest gtk3-based one. You might be able to change your title, but as far as the actual emulation goes, you'll miss out on hundreds of bugfixes and improvements (many of which are quite important) made during these last 4 years. Also, gnome-terminal is actively maintained, whereas terminator is unfortunately not, so even on the UI you might encounter more bugs. (There's an unstable branch of terminator using newest vte, but it _is_ quite unstable.) It's your call whether it's a price worth paying for being able to set the title.

(In reply to Steve Fink from comment #68)

> write(6, "\r\n\33]7;newtitle\7\r\n\33]0;cltbld@dev-linux64-ec2-sphink:[...]

No clue what's going on here. The newtitle and the following shell prompt are written in a single run, without a 2 second pause in between. Must be some weird shell or multiplexer or I don't know what. It really should work.

> I should note that I'm trying to switch to xfce4-terminal

That one's also based on gtk2's vte, so see my notes in the previous comment.

My bad, the title is 0, not 7:
echo -ne '\e]0;newtitle\a'; sleep 2

It's clear that your propmpt sets a new title, overriding the previous one. It's totally unclear to me why the sleep is not reflected.

I actually used 0 first, since that's what my finger memory told me, but it's no different.

Even if I unset PS1 and PROMPT1, it does nothing.

(In reply to Egmont Koblinger from comment #70)
> (In reply to Steve Fink from comment #68)
> 
> > I should note that I'm trying to switch to xfce4-terminal
> 
> That one's also based on gtk2's vte, so see my notes in the previous comment.

Ugh. Do you happen to know of another terminal emulator based on gtk3's vte, other than gnome-terminal? This isn't a complete showstopper for me, so I will probably give up soon and live with unnamed terminals. But I don't use any of the bells and whistles in my terminal program (despite spending all of my time there), so my resistance to switching is pretty low if something else happens to still support this functionality and not get in my way otherwise.

Ah! You were correct. I don't know why I was thinking of "PROMPT1"; unsetting PROMPT_COMMAND causes this to work. Yay! Still not as nice as being able to set the title via a shortcut key, but this makes the irritation livable. Thanks!

...and if I had actually *read* that strace output, I would have seen that it was indeed resetting the title immediately after... <covers face in shame>

(In reply to Steve Fink from comment #72)
> Ugh. Do you happen to know of another terminal emulator based on gtk3's vte,
> other than gnome-terminal? 

ROXTerm?

"GTK 3/VTE 2.90 build"

It has settable tab names.

I haven't used it thus far other than to confirm this, so FWIW.  But if the dark theme is possible without too much hassle I might use this instead of terminator.

> if the dark theme is possible

Follow-up - yes! roxterm uses a separate configuration program and the dark theme is available there  :-)

*** Bug 758906 has been marked as a duplicate of this bug. ***

So my "misguided tip" back in comment #38 broke after an upgrade (most likely a change in Gentoo's default bashrc/bash_profile). So I finally took some time to figure this out.

The latest iteration now looks like this:

function title()
{
	local t
	t=${1:-$(basename $PWD)}
	PS1="$PS1\[\e]0;$t\a\]"
}

For reference:

* "\[" and "\]" are Bash-specific escape sequences that disable and re-enable Bash's cursor position "algorithm" (without this, the tab title works but line endings are completely messed up). bash(1) mentions those sequences but doesn't really explain why they are needed, here's a better explanation [1]
* "\e]" is xterm's Operating System Controls [2]
* "0;here_be_some_text\a" is xterm's command to set the window title and icon [3]

Hope this helps other folks here.

Cheers

[1] http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html
[2] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-C1-_8-Bit_-Control-Characters
[3] http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Operating-System-Controls