2

I'm trying to set my TERM environment variable for tmux sessions in my .tmux.conf based on the value of TERM inherited from the parent shell (which is bash). Note that I have the following line in my .tmux.conf so that TERM actually gets inherited:

set -g update-environment '...some variables... TERM'

Basically, TERM is xterm-256color in the parent shell, and I detect that and set the default-terminal option using the following:

if "[[ ${TERM} =~ 256color ]]" 'set -g default-terminal screen-256color'

That line works in tmux 1.9a on my work PC (RHEL 6.6) and properly sets TERM to screen-256color, but on other PCs (including an Ubuntu PC at work running tmux 1.8 and my home Ubuntu PC running tmux 2.1), the 'condition' command always seems to be returning false, and so TERM is still screen inside the new tmux session.

I also tried doing if 'true' 'set -g default-terminal screen-256color', and that didn't work either! (TERM is still screen inside the new tmux session).

Could anyone help me figure out what I'm doing wrong? And maybe offer some info as to why it works on one machine but not on the other two?

UPDATE:

After running tmux with extreme verbosity turned on (tmux -vvvvvvvvvv), I think I see the issue.

Looking at the tmux server log file (tmux-server-xxxx.log), I see the following log lines, in this order (with other lines between them, which I've omitted):

run job 0x55fbca2e7240: [[ xterm-256color =~ 256color ]], pid 4955
cmdq 0x55fbca2dc250: new-session (client 7)
session 0 created
job died 0x55fbca2e7240: [[ xterm-256color =~ 256color ]], pid 4955

So it appears as though the new session is being created before the shell command exits, and so the session option isn't being set until later...but it is being set.

To confirm this, if I detach this session, edit .tmux.conf to comment out the line that checks $TERM/sets default-terminal, then create a new session, that new session has TERM = screen-256color.

Over on the RHEL computer where the command is working as expected, these log lines are appearing in a different order:

run job 0x1e82ce0: [[ xterm-256color =~ 256color ]], pid 17656
job died 0x1e82ce0: [[ xterm-256color =~ 256color ]], pid 17656
cmdq 0x1e66850: new-session (client 7)
session 0 created

...which is as expected. And TERM is set appropriately to screen-256color.

I'm not specifying the -b option to the if-shell command, so I'm not sure why my command appears to be executing in the background on these two Ubuntu macines. I wonder if this is a possible race condition in tmux?

Improve this question

1 Answer 1

Reset to default
5

I probably have an answer to your pre-update questions.

As stated here:

note that tmux uses /bin/sh -c to execute the shell command we specify. Thus, the command must be POSIX compliant, so tests of the form [[ are not guaranteed to be portable. Modern Ubuntu and Debian systems, for example, symlink /bin/sh to dash.

That was the thing in my case. Everything works after I replaced "your" method with the following: if-shell "echo $TERM | grep 256color" 'set -g default-terminal screen-256color'

Improve this answer
6
  • Didn't work for me unfortunately. I just tried this on a CentOS 7 machine with tmux 1.8 here at work, and I got the same race condition-like behavior as in the update above. Note too that the [[ method is working (somewhat) in the OP, just with the race condition behavior
    – villapx
    Commented Jun 27, 2017 at 19:12
  • 1
    What a pity. Could you try with your home Ubuntu PC running tmux 2.1 (that's the distro and tmux version that I have)? Note too that I didn't say it is impossible for [[ method to work, only that it's not guaranteed to work ;)
    – Toreno96
    Commented Jun 27, 2017 at 19:49
  • Wow, that seems to have solved it on that system (Ubuntu 16.04, tmux 2.1). Looking at the server log, it appears that the 'race condition' like behavior is no longer being exhibited, even in the case when I use [[. But, as you said, the [[ isn't guaranteed to work, and it indeed doesn't.
    – villapx
    Commented Jun 29, 2017 at 14:48
  • So it seems that the race-condition-like behavior was changed (fixed?) from tmux 1.8 to 2.1, but my bigger issue was that the CentOS and Ubuntu machines were not accepting the BASH syntax in the if-shell command. Thanks!
    – villapx
    Commented Jun 29, 2017 at 14:50
  • 1
    Right, that's what I'm guessing. I meant to say that in my comment; so tmux 1.8 seems to have an issue where it processes the if-shell condition job in the background, which apparently was fixed by or prior to 1.9a. But the bigger, perhaps more important problem, IMHO, was that I was using non-POSIX syntax, as you pointed out
    – villapx
    Commented Jun 29, 2017 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .