is_tmux_cc can fail to detect client control mode when there are multiple tmux sessions

[algal]

With tmux 3.3a, with iTerm 3.5.0beta25, on Debian bookworm, the script pbcopy.py fails to identify when it is running under tmux client control (CC) mode, the mode which offers native OS windows on iTerm2.

My testing indicates this is because the TMUX env variable does not always have the PID of the specific tmux process that was invoked with the -CC argument. For instance, when there are multiple tmux sessions running, I will be within the CC session but see a PID value in the TMUX var which corresponds to an entirely different tmux session, one which is not in client control mode. I do not know if this is expected behavior on the part of tmux.

For me, the result of this identification failure is that pbcopy.py thinks it is not running under client control, it use the wrong escape code, and it prints a backslash into the terminal when reading standard input.

I was able to resolve this on my fork by modifying the script to ask tmux directly if it is client control mode, by running tmux display-message -p #{client_control_mode}. This is the commit: algal@57efdbb

This fixes the issue I see, under the version numbers I mentioned. But I do not know if it is has narrower version support than the original version which inspects the TMUX var, finds a PID, and looks up command which launched the process.

[skaji]

For instance, when there are multiple tmux sessions running, I will be within the CC session but see a PID value in the TMUX var which corresponds to an entirely different tmux session, one which is not in client control mode.

It sounds like a bug on tmux's side.

[algal]

Yup.

Maybe asking tmux for client_control_mode will be less vulnerable to such bugs than chasing the PID? I am not sure.

But if I'm the only one running into this issue, it's not much of an issue.