I hate tmux because the way it handles switching windows is terrible. The model is switching between windows, each of which can have some layout of panes. This is approximately never what I want for a long-running thing I can detach from and reattach to, from a different terminal with different connections. Further, it supports multiple attachments by each having them see the same exact thing. For terminals that are different sizes, it shoves everything into an area the minimum height and width of all attached clients, and displays everything outside that as a field of periods.
I really prefer screen's functionality, instead.
Each pane can be independently switched to any of the pool of underlying ptys being managed.
The exact layout of panes is more of an ephemeral thing. On wide terminals I can split side-by-side, on narrow ones I can split top-above-bottom (and these can even be different for different clients connected to the server). It handles the multiple attached clients by only make
I think tmux's model is due to being too closely modeled on GUI virtual desktops.
That rant aside, tmux does have some nice features available by default that take a fair bit of configuration to get working well in screen.
tmux supports multiple sessions and switching between those. sessions behave independently like your screen windows. you can of course have multiple windows in each session, which then behave the tmux way.
you can also have the same window show up in multipe sessions and use that to emulate screen behavior. (i saw a script to help with that some time ago) for me, multiple sessions alone provide enough flexibility.
It probably technically does, in a horrifying Turing-tarpit way.
I actually did try to get the behavior I wanted out of nested tmux invocations and a hairy mess of scripts. There was no 'next-session' command (though now it looks like 'switch-client -l/-n/-p' would work. Hmm.)
I couldn't get it to work right, only a half-done approximation, and it involved way too many tmux interpositions.
Screen: client -> per client view of P panes -> P of entire pool of T terminals in session.
Tmux: client -> 1 of S sessions -> 1 of W windows -> P panes
To get splitting at the top level I need one top-level tmux client and its associated top-level session managed by one server. It can actually be locked to one window for what I care about.
In each of its panes, I need to run another tmux client so as to be able to actually change what final pty each pane will display. And each of these need to be separate sessions, so that I can display separate things in each of them. Each of these separate sessions will generally only have one window, with its implicit single pane. I should, of course, run all of these inner tmux sessions as a separate server from the top one.
Now I just have to make restricted keybindings for both the top and inner clients, and make make sure that any binding for the inner clients are replicated as "self-insert" in the top-level client. And remember that there are multiple places I can direct the command-lines (so need two bindings).
This results in the top level server having:
client -> session -> 1 window -> P Panes -> P clients
And the bottom server having:
P clients -> T sessions -> T windows -> T panes
And this doesn't yet let you have multiple top-level clients attached the way
screen does.
I'm sure I could eventually sand off all the sharp edges where it doesn't do what I want and make this work.
well if you want an exact emulation of screen behaviour, sure, that may be difficult. but i think you are making this a bit to complicated.
if what matters is that different clients can look at different windows, then using multiple sessions with one window each will get you exactly that.
you may of course need to get used to tmux way of switching sessions (which is not different than tmux way of switching windows). however, i just checked, there is a command to switch to the next session, and you can bind that to a key. add another keybinding to create a new session, and that should get you to about 90% of your expected behaviour without nesting tmux.
That last 10% matters. I absolutely need split windows, and being able to switch what is in the sub-panes easily. That's what require nesting.
The fact that it also doesn't have my preferred behavior for multiple clients connecting is just a minor nit-pick at that point. And I did say that the misnamed 'switch-client' would likely work.
Tmux has some very nice features: a nice commmand language, xterm-style mouse support, including both event binding and sending to client (pass through only), well thought out client-server separation, the ability for other programs to fairly easily drive it, visual identification of panes, menu-popups, and the default status-line is nicer.
All of that is merely nice to have, not actually needed though. It fundamentally doesn't have a model that works well for me. I wish it did, or that screen gains such things.
> That last 10% matters. I absolutely need split windows, and being able to switch what is in the sub-panes easily. That's what require nesting.
That could be solved by not relying on tmux for splitting, but on a terminal that has that feature, one ssh+tmux connection by panel.
In any case, it seems that you have put a lot of thinking about this, and probably already considered this solution.
I've been in the situation of trying to make my workflow perfectly fit in my new software/os/laptop/etc and not being able to make it work 100%. It's... sometimes exhausting. Nowadays I take another approach: make it fit well enough.
> well that would be like putting two terminals next to each other.
Pretty much! Not a perfect solution for sure.
I used to only rely on tmux, but nowadays I often prefer opening more terminals windows. I found out that by overly relying on tmux, I kept opened a way too high number of shells (browser tabs, anyone?).
Now for most tasks I open a terminal without tmux, that way I'm forced to close it if I don't want to have a cluttered desktop (I never minimize or hide windows, I don't even know how to do it on my wm).
> so you want each of the split windows behave like its own session or something, and switch terminals within that freely.
Exactly. Or at least that's one way to describe it, though it might also equally describe other things.
> so how does screen do that?
It's screen's native model.
'C-a |' (split -v) splits side-by-side and 'C-a S' (split) splits top-and-bottom. Screen calls these "regions". 'C-a X' (remove) will remove the current region, letting the sibling take the entire space again. 'C-a Q' (only) will replace the entire layout with the current region. 'C-a tab' (focus) will jump to the next region (it can take directional arguments to move up, down, left, and right, as well as 'prev' to go the opposite way of 'next', but these are not bound by default).
What tmux users would normally think of as window changing commands just switch the current region in the layout between viewing the entire pool of running commands.
> I think tmux's model is due to being too closely modeled on GUI virtual desktops.
Yes, using a terminal emulator that natively support tmux control mode (like iTerm2) is really nice because you can easily resize/rearrange the windows and panes via GUI actions, but absolutely suck when you have to reattach using a traditional terminal emulator because you now have to adjust all those windows and panes with keyboard actions.
If you require SSH features (e.g. port forwarding) or want to continue using your terminal's native scroll functionality, here's another alternative that a friend and I devised:
I hate mosh because it nukes scrolling. I hate tmux because I just can't remember the keybindings. I've been using mosh+byobu since the keybindings are a bit easier for me. But I'd love regular ssh to be resilient like mosh, or maybe mosh can start supporting scrolling.
I use mosh + screen, because you can tell screen to act like it has normal scrolling with a simple config and then the only keybinding you need to remember is disconnect.
Not much configuration, and slightly annoying that the config file is at $HOME/.screenrc instead of being patched to use an XDG location, but it's "good enough" for my use cases.
Doesn't seem to work for me. I use mosh to start the session, then screen to create a new screen. But this does not scroll using my mouse. I can scroll using Ctrl+A and then arrow keys. But that's not what I'd call normal scrolling.
Then your version of mosh is breaking on termcapinfo. I can't really help on your particular version, but that's not screen breaking. It has told mosh it supports scrolling with the mouse. Case of "works over here".
I got around the `tmux` barrier by writing down my most useful commands on an index paper, cutting it into the smallest rectangle I could (and folding in half), and tucking it in the pocket of my phone's flipcase (or you could stick it inbetween your smartphone and its back-shell).
As others have pointed out, mosh doesn't support port forwarding, and because ssh doesn't support udp forwarding, can't easily be used with proxyjump servers.
Story time: I had tmux sessions active on all our servers and would simply ssh into my work laptop from home, so the sessions were never really closed. One day, I decided to upgrade from 1404 to 1604 and closed out all my sessions (including on the servers because I was pushing out a new tmux config). After 5 minutes we started getting smss that the system was down and couldn't write to disk. One of our production servers had been set up with an encrypted home folder and when my session closed out, it closed the encrypted folder. Unfortunately, the ssh folder wasn't outside the encrypted portion, so we had to use IPMI to restore access. That's the story about how we started joking that closing my laptop is a great way to break the production system.
https://mosh.org/
https://eternalterminal.dev/
https://github.com/tmux/tmux/wiki