Otherwise, I'd be running tmux on my local machine, then want to run tmux on a remote machine, and nesting terminal multiplexers is not good.
I have a shell function called 'go' that creates a new screen and labels it, connects to the remote host via SSH, and then recreates or re-attaches to the remote scren as appropriate. My top level screen session currently has 8 remote hosts I'm logged into, each running their own nested screen sessions.
My go() function also reads my ~/.ssh/config file to grab all my host aliases so I can tab complete to them. Note, I'm a Perl programmer, and rarely write shell scripts, so this function may be kinda ugly.
go()
{
local OPTIND OPTARG
local SCREENCMD="screen -dRR"
while getopts "xn" flag; do
case "$flag" in
x) SCREENCMD="screen -xRR"; shift;;
n) SCREENCMD=""; shift;;
esac
done
if [ "$#" == "0" ]; then
echo "Need someplace to go."
return 1;
fi
while (( "$#" )); do
screen -t $1 ssh -tq $1 $SCREENCMD
shift
done
}
_go_show()
{
local curr opts
cur="${COMP_WORDS[COMP_CWORD]}"
opts=$(grep 'Host ' ~/.ssh/config | cut -d' ' -f2)
COMPREPLY=( $(compgen -W "${opts}" ${cur}) )
}
complete -F _go_show goIt kind of sucks if you accidentally use a hardstatusline in both the nesting and the nested muxes, and it slightly sucks if you use the same escape key for both/all levels of nesting.
I have been using a nested screen setup for ~3 years at home and it's great. My outer screen uses ^Z as its escape key (I ^Z very few commands) and the inner ones use ^O.
It works wonderfully, and I never have a problem remembering which screen has what because of the different escape keys. It's sort of like the finger memory that you develop if you use multiple workspaces (esp in a WM that supports tagging windows) and always keep the same things on the same workspaces.
also, using ^a^a to send commands to the nested tmux isn't so bad.. but to get to the third one down you need to use ^a^a^a^a as you need to send a ^a^a to the second one in..
for the fourth nest you need 8 ^a's, but again, it's a bit like code indentation, if you're 4 tmuxes deep, then there's a good chance you're doing it wrong
but still, it's nice to be able to do it if necessary
Tabbing and whatnot are something the WM (in my case, i3) handle far better than a specific program.
For example it also allows you to detach/reattach your running session, which is invaluable if you're working remotely, and especially if you have a flaky connection. I've used it in several instances where there is more than one person handling DB upgrades and the like. You can have several panes/tabs open, vim with upgrade notes, and everyone connecting and working as needed. It beats the crap out of constant copying/pasting pieces of code and terminals on some IM program to make sure everyone sees what you're seeing.
I usually also end up running it locally and bypassing the terminal emulator and WM's multiplexing abilities, but it's more out of a desire to use the same tool whether I'm running locally or on some remote box. If you don't need the latter, it's a bit harder to justify using it, even though it still has some advantages, like generally being more scriptable.
I use dtach(1) for this. I'm sure tmux is far more powerful, but dtach is much simpler and does all I need at this point. It's still less than a year since I learned Vim, so I'm taking a break from learning arcane programs with a zillion options for a while :P
also, running tmux locally has the advantage that if you need to leave the office or go somewhere, you can still reattach to your work machine and pick up from where you left off.. so, in a sense, everything is remote
Also, Is there any reason not to use just urxvt (without the client/daemon setup)? I've never had a crash that has brought down all of my clients, however.
at the time, I think I was on some kind of network where urxvt's terminfo wasn't likely to be installed anywhere. I know I could install it everywhere in ~/.terminfo or whatever, but it was a pain to get to a new host and realize that I hadn't set it up. I went back to xterm.
If you use a mac, I encourage you to try iTerm2/tmux-git. The combination allows you to reconnect to a remote tmux session and get a window with all of your tabs for that server. You'll never need to know the tmux commands again. You'll just use your native commands to switch tabs, search the history, see the list of open tabs, open new tabs, etc. This is the killer setup.
- Multi-plexing in the terminal
- screen/tmux
- multi-plexing in the WM
And it's pretty nice ! Written by hackers, for hackers.
I've been stacking screen sessions for years, so this is really exciting. Thanks!
Maybe these things can be enabled in tmux somehow? I know on a mac tmux/iTerm can do these things, but I'm on linux.
setw -g mouse-select-window on
setw -g mouse-select-pane on
setw -g mouse-resize-pane on
It's the price you pay for emulating a 35 years old piece of hardware[1] inside an emulator of the same...
With tmux's copy-mode, you can even select text without touching your mouse, using e.g. vim-like movements. Which is amazing feature.
The fact, that the copy-mode doesn't jump back down with every change on stdout is also very nice feature.
If you want to work with standard linux clipboard, you still can - just hold shift and select like in almost any linux TUI application.
On a random note, why do all unix applications (generalising I know) seem to default to a super-minimal set of options? Surely the kind of people who get annoyed by mouse integration (and you can just ignore it) are the kind of people who can find out how to turn it on, whereas those of us who are using tmux for the first time want all the nice options turned on by default?