Re:A tmux crash course (2016)
by ykevinator on Saturday December 29, 2018 @10:14AM
(#18783914)
Zoom is the best command, after using tmux for years, just discovered it. Ctrl-b z brings a pane into full screen and back. I use a 4x4 grid and zoom in and out.
Re:A tmux crash course (2016)
by rubyn00bie on Saturday December 29, 2018 @03:24PM
(#18785492)
I'm just curious- as I haven't really been able to get into tmux. Why use it as opposed to iTerm's built-in tabs and panes? Or like what are the selling points outside of just tabs and panes?
Re:A tmux crash course (2016)
by bigjimmyk3 on Saturday December 29, 2018 @03:31PM
(#18785518)
My initial attraction to screen / tmux was when I spent most of my time logged into remote servers. The ability to start a long-running script at the office, detach from screen, then re-attach at home to check on it later was indispensable.
Re:A tmux crash course (2016)
by mercer on Sunday December 30, 2018 @08:08AM
(#18788997)
Even better: use iTerm's tmux integration!
In my current workflow, I ssh into a server and then run "tmux -CCu attach -t main", which will open all the windows and tabs that I had open previously, but as regular iTerm windows and tabs. It's possible to also maintain tab/window colors and such, but I found all that to be a bit fiddly.
Re:A tmux crash course (2016)
by sys_64738 on Saturday December 29, 2018 @12:43PM
(#18784717)
Binding isn't an option as only defaults are available on target machines (can't save .screenrc file). There can be thousands of target machines so binding doesn't scale.
Re:A tmux crash course (2016)
by blevs on Saturday December 29, 2018 @09:49PM
(#18787058)
I'm sorry I wasn't clear. This would be a binding in your local tmux configuration that sends the prefix command to whatever is in your current pane, allowing you to have a key act as a 'remote prefix' button.
I agree that bindings still don't scale incredibly well depending on the number of host machines you need to ssh from. I think your screen workaround is a pretty neat solution.
Re:A tmux crash course (2016)
by mdaniel on Saturday December 29, 2018 @12:15PM
(#18784558)
I suppose you mean that you run tmux locally and then you ssh into a server and run screen remotely?
If so, I wonder how hard it would be to make tmux into a client of itself using control mode. I only learned about control mode when I discovered iTerm2's tmux integration, whereby remote tmux windows materialize as "actual" terminal windows on my desktop. However, for the same reason that iTerm2 can resize a window, create a new one, show and hide them, etc, I would _imagine_ it's possible to have your remote tmux windows materialize as tmux windows in your local tmux, and thus would be managed using only a single prefix key.
I would guess such a capability would need to be baked into tmux, but I actually wonder how much code would actually be required, since control mode already exists and clearly works quite well.
Re:A tmux crash course (2016)
by sys_64738 on Saturday December 29, 2018 @12:42PM
(#18784712)
ssh to remote server over VPN then tmux attach, then connect to target machine and launch screen to work multiple sessions on target machine as it's not networked.
... I mostly just want to be sold on it :)
In my current workflow, I ssh into a server and then run "tmux -CCu attach -t main", which will open all the windows and tabs that I had open previously, but as regular iTerm windows and tabs. It's possible to also maintain tab/window colors and such, but I found all that to be a bit fiddly.
For example, to bind C-a to control the remote session:
I agree that bindings still don't scale incredibly well depending on the number of host machines you need to ssh from. I think your screen workaround is a pretty neat solution.
If so, I wonder how hard it would be to make tmux into a client of itself using control mode. I only learned about control mode when I discovered iTerm2's tmux integration, whereby remote tmux windows materialize as "actual" terminal windows on my desktop. However, for the same reason that iTerm2 can resize a window, create a new one, show and hide them, etc, I would _imagine_ it's possible to have your remote tmux windows materialize as tmux windows in your local tmux, and thus would be managed using only a single prefix key.
I would guess such a capability would need to be baked into tmux, but I actually wonder how much code would actually be required, since control mode already exists and clearly works quite well.