After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711060 - Always update the terminal title for the running command
Always update the terminal title for the running command
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks: 711059
 
 
Reported: 2013-10-29 09:30 UTC by Allan Day
Modified: 2021-06-10 20:36 UTC
See Also:
GNOME target: ---
GNOME version: 3.11/3.12


Attachments
screen: Update the title with the current foreground process (4.44 KB, patch)
2014-06-25 13:22 UTC, Debarshi Ray
none Details | Review
screen: Update the title with the current foreground process (5.06 KB, patch)
2014-07-10 17:18 UTC, Debarshi Ray
none Details | Review
screen: Update the title with the current foreground process (7.59 KB, patch)
2014-07-14 15:09 UTC, Debarshi Ray
none Details | Review
[vte] Support preexec notifications from an interactive shell (6.77 KB, patch)
2018-05-09 16:16 UTC, Debarshi Ray
none Details | Review
[vte] Test the shell-preexec signal (2.03 KB, patch)
2018-05-09 16:16 UTC, Debarshi Ray
none Details | Review
[vte] Support precmd notifications from an interactive shell (5.08 KB, patch)
2018-05-09 16:16 UTC, Debarshi Ray
none Details | Review
[vte] Test the shell-precmd signal (1.98 KB, patch)
2018-05-09 16:17 UTC, Debarshi Ray
none Details | Review
[gnome-terminal] screen: Update the title with the current foreground process (5.82 KB, patch)
2018-05-09 18:01 UTC, Debarshi Ray
none Details | Review
[gnome-terminal] screen: Update the title with the current foreground process (8.24 KB, patch)
2018-05-10 16:23 UTC, Debarshi Ray
none Details | Review
[gnome-terminal] screen: Monitor changes to the current foreground process (5.31 KB, patch)
2018-05-16 14:10 UTC, Debarshi Ray
none Details | Review
[gnome-terminal] screen: Try harder to find a foreground process group member (1.97 KB, patch)
2018-05-18 18:29 UTC, Debarshi Ray
none Details | Review

Description Allan Day 2013-10-29 09:30:23 UTC
I have "When terminal commands set their own titles" set to "Replace initial title". This works some of the time - eg. "jhbuild build" will update the tab title.

However, most commands do not work. Examples:

 * jhbuild run
 * git pull -r
 * yum update

Ideally this option would work for every command that you use.
Comment 1 Bastien Nocera 2013-11-14 15:16:57 UTC
It's those applications setting the title, not the terminal changing it for them though.
Comment 2 Allan Day 2013-11-22 11:44:44 UTC
(In reply to comment #1)
> It's those applications setting the title, not the terminal changing it for
> them though.

I think we should consider whether this is something that the terminal should be doing for apps.
Comment 3 Debarshi Ray 2013-11-27 12:24:15 UTC
(In reply to comment #0)
> I have "When terminal commands set their own titles" set to "Replace initial
> title".

For what it is worth, that option is gone since 3.9.90:

commit f27bf0135a2d18ba22158d28bf1f8c5f6ec066c8
Author: Christian Persch <chpe@gnome.org>
Date:   Fri Jun 21 15:33:53 2013 +0200

    screen: Simplify terminal title handling
    
    Remove all the options.

When terminal commands set their own titles, the initial title is always replaced.
Comment 4 Allan Day 2014-01-21 18:29:36 UTC
(In reply to comment #3)
...
> For what it is worth, that option is gone since 3.9.90:
...

I'm using 3.10.2, and I still see that option.
Comment 5 Christian Persch 2014-01-21 21:07:56 UTC
That's because 3-10 was branched from 3-8, not master.
Comment 6 Debarshi Ray 2014-06-25 13:22:31 UTC
Created attachment 279220 [details] [review]
screen: Update the title with the current foreground process

Trying out an idea suggested by rtcm. Not very reliable, but kind of works. It can detect stuff launched in the background with &, ctrl+z followed by fg or bg. However, if you running your shell nested within another, then keeping the enter key pressed will cause the window title to flicker.
Comment 7 Debarshi Ray 2014-07-10 17:18:42 UTC
Created attachment 280426 [details] [review]
screen: Update the title with the current foreground process

This works much better with nested shells than before. We just skip the key stroke immediately after the title has been updated. If the title was changed by COMMAND_PROMPT or precmd_functions then we are currently showing the prompt and the next key is either an empty ENTER or something else, neither of which is interested for us. If the title was changed by an application then we don't need to bother anyway.

This works with ctrl+z, bg, fg.

'/bin/echo; emacs -nw' shows up as emacs, but 'sleep 5; emacs -nw' shows up as sleep. I am not too bothered with this because the Mac OS X terminal shows 'git log' and 'man ls' as less, which is a much common case than 'sleep 5; emacs -nw'.

We could fix that by exploring cgroups - we can put the shell in its own cgroup and listen for notifications where a new foreground process is spawned. I am not 100% sure how all that would work, but as I said, I think this is a reasonable start.
Comment 8 Debarshi Ray 2014-07-14 15:09:03 UTC
Created attachment 280651 [details] [review]
screen: Update the title with the current foreground process

chpe suggested that we guard this behaviour behind a setting. I have added a show-foreground-process-in-title profile setting for that.
Comment 9 Matthias Clasen 2014-08-10 17:47:31 UTC
this would be very nice to have for 3.14 - any chance to get a rewiew here ?
Comment 10 Christian Persch 2014-08-16 17:04:08 UTC
Review of attachment 280651 [details] [review]:

I have to say I don't like this approach too much…

So this shows either the application-set window-title, or the process-name as title, depending on the order of some events… that seems rather fragile.

::: src/org.gnome.Terminal.gschema.xml
@@ +166,3 @@
     </key>
+    <key name="show-foreground-process-in-title" type="b">
+      <default>true</default>

false

::: src/terminal-schemas.h
@@ +57,3 @@
 #define TERMINAL_PROFILE_SCROLL_ON_KEYSTROKE_KEY        "scroll-on-keystroke"
 #define TERMINAL_PROFILE_SCROLL_ON_OUTPUT_KEY           "scroll-on-output"
+#define TERMINAL_PROFILE_SHOW_FOREGROUND_PROCESS_IN_TITLE "show-foreground-process-in-title"

...._KEY

::: src/terminal-screen.c
@@ +1536,3 @@
+    }
+
+  if (event->keyval == GDK_KEY_Return || event->keyval == GDK_KEY_KP_Enter)

What about ISO_Enter and 3270_Enter ? And I see there's now *another* one, RockerEnter, no idea what that's about...
Comment 11 Matthias Clasen 2014-12-04 00:12:38 UTC
In gtk, we generally treat GDK_KEY_Return, GDK_KEY_KP_Enter and GDK_KEY_ISO_Enter the same, and ignore the others.
Comment 12 Matthias Clasen 2015-06-15 16:46:06 UTC
Ping ? Would this patch be acceptable if we make it handle other Enter variants
Comment 13 Christian Persch 2015-06-17 18:25:14 UTC
Maybe gtk+ should export a macro in the GDK_KEY_ namespace that checks the keyval for all the enter variants, so that every programme can be consistent in this…

Is this one of the patches that fedora ships? If so, has there been any feedback from users on whether they like the feature, or about problems with the implementation (wrong title shown at some point)?
Comment 14 Debarshi Ray 2015-06-17 18:55:22 UTC
(In reply to Christian Persch from comment #13)
> Is this one of the patches that fedora ships?

No.

> If so, has there been any
> feedback from users on whether they like the feature,

Terminal.app on OS X has been doing it for a while, and there are some other terminals both on OS X and Linux (eg., Konsole) that do this. Unfortunately, all the free software ones use polling, which is bad. :(
Comment 15 Debarshi Ray 2018-04-19 14:55:37 UTC
I wonder if Bash 4.4's PS0 [1] is the equivalent of Z shell's preexec that we have been asking for.

We can use vte.sh to setup PS0 to emit an escape sequence, and then the terminal emulator could use tcgetpgrp to read the foreground process name and set the window title. The escape sequence would stand for "about to execute command interactively".

[1] Egmont mentioned it here: https://bugzilla.gnome.org/show_bug.cgi?id=711059#c79
Comment 16 Debarshi Ray 2018-05-04 15:17:27 UTC
I have a prototype where PS0 emits a new VteTerminal::shell-preexec signal to prompt the terminal application to look at the current foreground process group and update the title. Will attach the patches after cleaning them up.
Comment 17 Debarshi Ray 2018-05-09 16:16:10 UTC
Created attachment 371856 [details] [review]
[vte] Support preexec notifications from an interactive shell
Comment 18 Debarshi Ray 2018-05-09 16:16:32 UTC
Created attachment 371857 [details] [review]
[vte] Test the shell-preexec signal
Comment 19 Debarshi Ray 2018-05-09 16:16:48 UTC
Created attachment 371858 [details] [review]
[vte] Support precmd notifications from an interactive shell
Comment 20 Debarshi Ray 2018-05-09 16:17:04 UTC
Created attachment 371859 [details] [review]
[vte] Test the shell-precmd signal
Comment 21 Debarshi Ray 2018-05-09 18:01:57 UTC
Created attachment 371867 [details] [review]
[gnome-terminal] screen: Update the title with the current foreground process
Comment 22 Debarshi Ray 2018-05-10 16:23:01 UTC
Created attachment 371903 [details] [review]
[gnome-terminal] screen: Update the title with the current foreground process

Restore the show-foreground-process-in-title GSetting that got lost, and changed the default to "false".
Comment 23 Debarshi Ray 2018-05-16 14:10:13 UTC
Created attachment 372123 [details] [review]
[gnome-terminal] screen: Monitor changes to the current foreground process

I was experimenting with monitoring the activity on the pseudo-terminal device (ie. VteTerminal::contents-changed) to detect when the foreground process might have changed.

This helps with commands like "emacs; vim".  Bash won't emit a notification when emacs terminates and vim starts, so monitoring terminal activity is a way to catch that.  This also works when a program is run from the (gdb) prompt, but I am not sure we want to update the title in that case.

I don't know if it's a good idea to repeatedly invoke tcgetpgrp whenever there's any pseudo-terminal activity.  It's currently batched using a 500 ms timeout, which seems ok-ish - my only measurement was to run "time ls -R" in my home directory which has loads of git trees, including some big ones like glibc.git, linux.git and libreOffice/core.git, and I didn't notice any noticeable slowdown.

Either way, I thought that it would be good to at least experiment with this, since this one of the things that KDE's Konsole does.  Relying only on this approach seems a bit limiting because it's hard to detect nested shells - the child shell will look like an ordinary foreground process like emacs.  It works for Konsole because it doesn't differentiate if the foreground process is the shell or an application - if there's no application running, it just shows the name of the shell.  However, if you want to draw that distinction, then it will look odd if that doesn't work reliably.
Comment 24 Debarshi Ray 2018-05-16 14:12:18 UTC
The patches are also in the following branches:
vte.git:wip/rishi/precmd-preexec
gnome-terminal.git:wip/rishi/auto-title-notify
Comment 25 Debarshi Ray 2018-05-18 18:29:20 UTC
Created attachment 372198 [details] [review]
[gnome-terminal] screen: Try harder to find a foreground process group member

Since there's no user-space API to list the members of a process group, other than crawling through /proc, this tries a bit harder to find a surviving member of the group so that we can show a window title for commands like:
  $ cat /proc/meminfo | less
Comment 26 GNOME Infrastructure Team 2021-06-10 20:36:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7379.