Control Mode Specification

[Jason Gauci]

I created a remote shell client/server called EternalTerminal ( https://mistertea.github.io/EternalTCP/ ) that supports tmux with control mode and control mode is amazing.

What's not amazing is that control mode only works with iTerm and OS/X.

I would be willing to spend the time forking a cross-platform terminal emulator to support tmux control mode but without any documentation or a spec, there's no way I could build this reliably and ensure it's fully compatible.

Can someone on the tmux team take a few minutes to write a spec?  Thanks.

[Nicholas Marriott]

Hi

George Nachman wrote a spec when he originally did the work, it is
probably on his site somewhere and will probably give you the basic
idea, although it is no doubt out of date in places.

Otherwise for anything beyond what is in the tmux manual, you will need
to look at the tmux and iterm2 code, but feel free to ask me questions
if you need to.

On Wed, Feb 01, 2017 at 03:54:14AM +0000, Jason Gauci wrote:
> I created a remote shell client/server called EternalTerminal

> (**[1]https://mistertea.github.io/EternalTCP/**) that supports tmux with

> control mode and control mode is amazing.
> What's not amazing is that control mode only works with iTerm and OS/X.
> I would be willing to spend the time forking a cross-platform terminal
> emulator to support tmux control mode but without any documentation or a
> spec, there's no way I could build this reliably and ensure it's fully
> compatible.

> Can someone on the tmux team take a few minutes to write a spec?** Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [2]tmux-users+...@googlegroups.com.
> To post to this group, send email to [3]tmux-...@googlegroups.com.
> For more options, visit [4]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. https://mistertea.github.io/EternalTCP/
> 2. mailto:tmux-users+...@googlegroups.com
> 3. mailto:tmux-...@googlegroups.com
> 4. https://groups.google.com/d/optout

[hiro neu]

Hey Nicholas,

I am in the same position as Jason and would like to understand this control protocol.

Sadly the man page does not provide a basic overview how I am supposed to interface this most easily, trial&error seems to suggest communication is via stdin/out, but I'm unable to see what commands might be useful to start with.

I tried to understand what is happening by running a normal tmux session but the printed events are not very complete, i.e. they aren't equivalent to the commands that i would have to be sending to tmux to recreate the actions from my interactive usage. In other words it seems I am able to observe the results by checking stdout, but am unable to find commands that would *cause* the same thing.

Also, I have no iterm so i can not experiment with that (would be trivial for me to just dump all data sent by iterm over that FD).

I was unable to find George's website, he shows up a trillion times on google, do you have a more specific link? i don't care if it's outdated as long as I get an overview, the basic idea.

I also have small questions: like, does iterm really use panes in the server side tmux session? bec. i was not able to figure out a way to zoom into a pane and attach it to one terminal emulator while leaving the window with the pane alone so that another terminal can zoom into another pane of the same window.

thank you,

hiro

[Nicholas Marriott]

Hi

You can look at https://github.com/tmux/tmux/wiki/Control-Mode.

I don't know how iTerm2 operates unfortunately, I only know how it uses control mode.

To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/beb865a7-6420-472d-bf88-5daa1cf9f332n%40googlegroups.com.

[hiro]

thanks, i figured out this is much more low-level than i thought.
it makes tmux nearly disappear, which is *curious*.
tmux could be replaced by something that doesn't do curses, that only
connects the FDS and muxes them all into this control mode protocol.
it seems just incidental that people are willing to still using tmux
in the background even though 99% of the "terminal emulation" task is
done in iterm. crazy :D

i wanted something similar, but since i already use a tiling window
manager i didn't want any of the window management overhead of using
tmux or using fancy terminal emulators, so i would be really curious
about a much more lightweigt dedicated control-mode server some day,
then i might even implement a client after all :D

in the meantime i hacked together something else that serves my needs
for now, i run this from my window manager depending on window
title/props string (wmii), and this way i can stay inside a remote ssh
context but use my full local window management.
and of course i can re-attach all those windows easily after some reboot.

i'm not bothering about window panes, i demand there's one pane per
window, otherwise it doesn't work. i don't need such deep hierarchies
as my window manager already is complicated enough.

thought of calling it something like tmuxcollapse or so, but tunmux was shorter.
i had a lot of fun today with this. it's a bit like opening a box of
springs when those 100 windows jump out,

#!/bin/sh

newwin(){
$remotecmd tmux new-window -dP -F'#{window_index}' -t $1 || echo error
}

attach_win() {
CLIENTID=$1-$2-"`date +%Y%m%d%H%M%S`"
#rxvt hotfix
yes ' '|sed 300q
# recover scrollback
$remotecmd tmux capture-pane -p -J -S- -E- -t$1:$2
[ -n "$remotecmd" ] && remotecmd="$remotecmd -t"
[ -z "$remotecmd" ] && remotecmd=eval
$remotecmd "tmux new-session -d -t $1 -s $CLIENTID\; \
select-window -t $2\; \
set status off \; \
set-option destroy-unattached\; \
set-hook pane-exited detach-client\; \
setw -g aggressive-resize on\; \
attach-session -t $CLIENTID"

}

error(){
echo error: $*
exit
}

attach_one(){
name=$1
window=$2
export remotecmd
urxvt -name "mux $remotecmd $name $window" -title "mux $remotecmd
$name $window" -e sh -c "tunmux attach_win $name $window"
}

attach_all(){
echo attach_all args: $* remotecmd: $remotecmd
name=$1
[ $name = "s" ] && error cant be named after ssh option
shift
$remotecmd tmux list-windows -t $name 2>/dev/null || (
$remotecmd tmux new-session -d -s $name
$remotecmd tmux set-option -g bell-action current
)
( if [ -z "$1" ]
then
$remotecmd tmux list-windows -F'#I' -t $name
else
while [ -n "$1" ]
do
echo "$1"
shift
done
fi
)|
while read line; do
window=$line
attach_one $name $window &
sleep 0.05
done
}


usage(){
error blablabla
}

echo main args: $* remotecmd: $remotecmd
[ -z "$1" ] && usage
case $1 in
s)
shift;
[ -z "$1" ] && usage
#export remotecmd="ssh $1"
remotecmd="ssh $1"
shift;
[ -z "$1" ] && usage
;;
esac
case $1 in
attach_win)
#only indirectly through attach_all and urxvt
shift
attach_win $*
exit
;;
newwin)
shift
win=`newwin $1`
if [ "$win" = "error" ]
then
attach_all $1
exit
fi
attach_one $1 $win
exit
;;
*)
attach_all $*
exit
esac

>> <https://groups.google.com/d/msgid/tmux-users/beb865a7-6420-472d-bf88-5daa1cf9f332n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>