Hello, With the recently stabilized app-shells/bash-5.1_p16-r10, I applied the new config, now it sources /etc/bash/bashrc.d/10-gentoo-color.bash /etc/bash/bashrc.d/10-gentoo-title.bash to set color & title, but now when I connect remotely to the box, it fails to set the window title. In /etc/bash/bashrc.d/10-gentoo-title.bash case ${TERM} in screen*|tmux*) genfun_set_pane_title() { printf '\033k%s\033\\' "${HOSTNAME%%.*}" } PROMPT_COMMAND+=('genfun_set_pane_title') ;; *) # If the TTY is that of sshd(8) then proceed no further. Alas, # there exist many operating environments in which the window # title would otherwise not be restored upon ssh(1) exiting. if [[ ${SSH_TTY} && ${SSH_TTY} == "$(tty)" ]]; then return fi esac If I comment the ssh block, then it works fine and window title (and in tabs) is correctly set. If I don't, then, the window title remains to my local shell instead of showing remote session username@hostname window title. Reproducible: Always
Thank you for the report. The reason this change was made is as described by the comment in the code but I'll begin by putting it in more detail. Imagine a world in which Gentoo Linux was the only operating system that existed, or - at least - was the only operating system on which people chose to run SSH clients and servers. In such a world, setting the title unconditionally would be fine because it could be reasonably assured that the title would be restored upon exiting the remote shell. That is, the sequence of events would be as follows: 1. User executes ssh(1) on Gentoo to acquire remote shell 2. Remote session begins (n.b. server has no idea what the original title was) 3. Remote shell customises the title 4. User eventually quits ssh(1) on the client side 5. Client-side shell resumes control 6. Because the client OS is also Gentoo, it sets the title again (obviating #2) Therein lies the rub. We do not live in such a world. That is, just because sshd(8) happens to be running on a Gentoo Linux system, it does not necessarily follow that we only connect to it from Gentoo Linux systems. Sadly, there is no practical way for any application running in a terminal to know what the current window title is before it goes and sets a different one. With SSH it gets worse, because - other than the value of the TERM variable - the server has absolutely no knowledge of the client-side operating environment whatsoever! To put it in perspective, here is a concrete example of what could happen prior to this change. I'll use macOS for the sake of this example here but do note that there are plenty of other operating environments in which this would occur, including some Linux distributions. 1. User executes ssh(1) on macOS to acquire remote shell on sshd(8) on Gentoo 2) Remote session begins (again, server has no idea what the title was) 4) Remote shell customises the title 5) User eventually quits ssh(1) 6) Client-side shell resumes control 7) Because the OS does not set the title at every prompt, the title isn't restored So, in this scenario the title ends up being stuck with the details of the remote host even once I've logged out of it. To restore the original title, I have no choice but to either: a) manually emit a sequence to set the title b) customise the client-side operating environment to always emit a title at prompt c) customise the server-side environment so that it leaves the title alone d) always run tmux or screen on the remote side (they render titles independently) (It's worth noting that (c) used to be highly impractical to accomplish in Gentoo. Part of this change was about disentangling the opinionated Gentoo title setting behaviour so that users could readily exercise more control over it.) Essentially, there is no way to go about it in a default way that pleases everyone but I would hope that this demonstrates why I think it is fundamentally wrong for a shell spawned by sshd(8) to unconditionally interfere with the title. Again, there is no way for the remote shell to have any concrete knowledge of what the client-side environment is and how it behaves. I wonder whether we could perhaps reach some middle ground here. In re-considering how 10-gentoo-title.bash behaves, it occurs to me that the "genfun_set_pane_title" shell function doesn't really have to be declared on an unconditional basis. Instead, we could declare the function unconditionally. That way, it would be much easier for users such as yourself - i.e. those that aren't concerned with foreign client-side environments - to restore the previous behaviour of setting the title unconditionally over SSH. For example, the ~/.bashrc on the remote side could then simply contain: # Make the shell set the window title, no matter what. PROMPT_COMMAND+=(genfun_set_pane_title) Or, for example, it could then be the subject of a user-defined /etc/bash/bashrc.d/ drop-in.
Forgot to add to items a - d ... e) launch a new terminal (annoying)
Also, my apologies, I meant to declare the "genfun_set_win_title" function unconditionally, not "genfun_set_pane_title".
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b35701d05b15a831d8319c046203f7a70be339cb commit b35701d05b15a831d8319c046203f7a70be339cb Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2024-06-15 03:59:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-15 04:39:29 +0000 app-shells/bash: declare the genfun_set_win_title function unconditionally Presently, revisions 5.1_p16-r10, 5.2_p26-r3 and bash-5.3_alpha-r2 refrain from declaring the genfun_set_win_title function at all in the case that the tty belongs to sshd(8). This is to avoid cluttering the shell's operating environment in situations where the decision is made not to append 'genfun_set_win_title' to the PROMPT_COMMANDS array. One might ask why it should not always be appended to the array. The explanation for this is that Gentoo Linux does not exist in a vacuum; not all operating systems default to initialising bash in such a way that it can be assumed that the title will be set at each prompt (or at all). Where SSH is involved, the server has no knowledge whatsoever of the particulars of the client OS or its operating environment. This would previously give rise to the following scenario. 1. User runs ssh(1) from non-Gentoo to connect to sshd(8) on Gentoo 2. The remote shell alters the window title 3. The user eventually exits the remote shell. 4. The window title is never restored to its prior value Put simply, there is no way for the remote side to know what the existing window title is, much less guarantee that it be restored on the client side. All that being said - and rather unsurprisingly - some Gentoo users will care nothing for these considerations or are simply operating in a homogenous environment where they are not an immediate concern. Try to accommodate the wishes of such users more effectively by declaring the function unconditionally. Consequently, they will have the option of restoring Gentoo's historical behaviour in a somewhat straightforward manner. That is, by setting PROMPT_COMMAND in ~/.bashrc or in an /etc/bash/bashrc.d/ drop-in to the effect of the following. PROMPT_COMMAND=(genfun_set_win_title) Signed-off-by: Kerin Millar <kfm@plushkava.net> Bug: https://bugs.gentoo.org/934309 Signed-off-by: Sam James <sam@gentoo.org> ...-5.1_p16-r10.ebuild => bash-5.1_p16-r11.ebuild} | 0 ...sh-5.2_p26-r3.ebuild => bash-5.2_p26-r4.ebuild} | 0 ....3_alpha-r2.ebuild => bash-5.3_alpha-r3.ebuild} | 0 .../bash/files/bashrc.d/10-gentoo-title.bash | 49 +++++++++++++--------- 4 files changed, 29 insertions(+), 20 deletions(-)
As the screen maintainer I need to comment on the recent title changes, which are wrong from my point of view. For both screen and tmux the window title that is updated with the k escape sequence is an alias that is given to the window by the user and the alias can be used to reference the window in commands, e.g. "select <alias>" in screen or "select-window -t <alias>" in tmux to switch to a window by name. This is why the title should not be changed by applications running inside of screen or tmux. Also the k escape sequences in tmux changes the window title and not the pane title like is written in the comment of genfun_set_pane_title, making the result of the window title arbitrary for windows with multiple panes in them. Both screen and tmux support a title string like the xterm title. In screen, this is called the hardstatus line and tmux calles it the pane title. Both are updated by the xterm title sequence as part of genfun_set_win_title and both forward the title to the terminal. As said, I consider these changes wrong and am preparing a patch to remove genfun_set_pane_title from the bashrc.
(In reply to Sven Wegener from comment #5) Many thanks for reporting and I regret having inconvenienced you. Not to be bureaucratic but, given that the issue that you raise is largely distinct from this one, I shall file a new bug on your behalf, copy you in and respond there.
I filed bug 934732 to address Sven's report.
I've found this change particularly annoying, and deleted those lines when my annoyance passed certain critical threshold: # Proceed no further if the TTY is that of sshd(8) and if not running a terminal # multiplexer. Alas, there exist many operating environments in which the window # title would otherwise not be restored upon ssh(1) exiting. Those who wish for # the title to be set unconditionally may adjust ~/.bashrc - or create a custom # bashrc.d drop-in - to define PROMPT_COMMAND=(genfun_set_win_title). if [[ ${SSH_TTY} && ${TERM} != @(screen|tmux)* && ${SSH_TTY} == "$(tty)" ]]; then return fi
Why not do as the comment says? > Those who wish for the title to be set unconditionally > may adjust ~/.bashrc - or create a custom bashrc.d drop-in > - to define PROMPT_COMMAND=(genfun_set_win_title).
Not disclosing too many details, It's not single user operation.
That can still be done in /etc/bash/bashrc.d.
Well, yes, could be done nicer, been too fast in deleting thinks that annoyed me.
