Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have begun using tmux recently to really improve my terminal sessions. One thing I need to be able to do is connect to a remote server, which is also running tmux. However, I have found that the current window title (denoted as #T in tmux) is not updated while within a secondary tmux shell. I would like to update the primary-tmux-session value from within the secondary session.

"#T" clearly takes on the value processed by PROMPT_COMMAND, which is a command run every time the prompt is reloaded. However, if I connect to a remote server, it opens a server-side-shell, which then opens tmux and this runs a completely new shell within the secondary-tmux session. The only way I know how to update the primary tmux window title is to reload the server-side-shell prompt, but this does not happen from within a secondary tmux session.

Is there any command to connect the two sessions so that they share #T ? I originally thought it might be doable with the terminal-overrides option, but it either does not work or I have set it up wrong.

Any thoughts or suggestions would be greatly appreciated. Thank you!

(PS. I suspect this question is better suited to superuser, but I had previously asked a question on stack-overflow. I hope this is the right forum for this sort of question)

share|improve this question

1 Answer 1

up vote 2 down vote accepted

I did some digging and found the answer for myself. Well, the way I have found to accomplish my gaol is not elegant, but it will work to get the job done.

First, you need to have the "set-titles" option turned on in your .tmux.conf file. As well as the appropriate title string:

set -g set-titles on
set -g set-titles-string '#T'

However, if you implement this, you will immediately notice that it doesn't work. The problem is that this only sends the title string up stream if it starts in an xterm variant (tmux/screen TERM variable is "screen*"). So, when starting a nested tmux session, you must fool the terminal by resetting the variable. The following example will keep the TERM suffix (e.g. "-256color").

TEMP_TERM=$TERM
TEMP_TERM_SUFFIX=${TERM#$(echo $TERM | cut -f 1 -d'-')}
TERM="xterm${TEMP_TERM_SUFFIX}"

I am not sure if it matters, but I think it is smart to reset TERM back after closing tmux (so save it into a temp variable). Using this, a simple shell script can be made to open a nested tmux session that sends the #T title variable upstream to it's parent sessions.

This all works, but is somewhat of a pain considering that work must be done to ensure infinite nesting loops aren't created in the event that we automatically start our shell up in tmux. If anyone has a better solution I would love to here it as well!

share|improve this answer
    
From the tmux man-page: “The TERM environment variable must be set to screen for all programs running inside tmux. New windows will automatically have TERM=screen added to their environment, but care must be taken not to reset this in shell start-up files.” –  ELLIOTTCABLE Nov 4 '11 at 16:29
    
@elliottcable yes, you are right, it does say that. My solution to this problem is more or less a hack. This can mess up your session and may even freeze up slow computers, but I am not certain this is something I am worried about. For example, if you reset TERM to anything other than screen* then you end up running tmux attach-session -t $(tmux display -p "#S") you will setup an infinite loop of tmux nested sessions (chaos!). I am not sure of any other, more extreme examples of possible problems, but you should certainly avoid infinite loops :) –  scicalculator Nov 22 '11 at 6:51
    
@elliottcable I just want to add one more point. If you use this and are worried, I suggest doing it ONLY before attaching to a session that does not display the same pane AND you should reset the variable after your session detaches export TERM=$TEMP_TERM –  scicalculator Nov 22 '11 at 6:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.