Theo’s endorsement (from when tmux got imported) spreads fuzzy warm feelings:
To me, the biggest advantage of tmux over screen is that you can google for it by name. Searching for “screen” is unreliable at best (“GNU screen” sometimes helps, but discards some useful results).
Google’s DWIM has gotten better since I made the definitive switch, but it’s hard for me to imagine going back to this mess (-:
I would like to point out that this article is from 2010, and it references needing a custom patch to do vertical splits in screen. That patch has since been merged in and a stable release made.
[Comment removed by author]
That’s trivially changed.
Haha! Sorry! I thought you were questioning why ctrl-b was the prefix! “I like tmux a lot, but ctrl-b??”
I’m pretty sure the answer for that is because they were using screen while starting to build tmux.
That, and it really needed to be something other than control-a (which screen uses). Any choice is going to conflict with emacs keybindings, but that was one of the worst possible. :)
Control-B conflicts the backward key in emas mode shell command editting , I use Control-\ instead.
But that conflicts with toggle-input-method!! /s
Ah, but it does overlap with the key normally used to send SIGQUIT, which can ooccasionally lead to unintentionally killing processes if you hit it out of habit when not in tmux/screen or by accidental double-triggering (I use both tmux and screen regularly and have both set up to use C-\). Granted, you can adjust that with stty, but I’ve never actually bothered.
This outlines exactly why I’ve stuck with tmux for such a long time! :)
One small thing, though - and maybe I’m misunderstanding - but it was my understanding that screen received native support for vertical splits sometime around two years ago.
I was a long-time user of Screen, but I felt like even after five years I was still always looking up the keys for scrollback because I used it infrequently enough, and there was no way to make it just work like Emacs. Switching to tmux made me feel more at home immediately. Also the fact that you have to install Screen as setguid root just in order to share sessions with another user always made me nervous; tmux’s support for using sockets instead makes way more sense.
Also the fact that you have to install Screen as setguid root just in order to share sessions with another user always made me nervous; tmux’s support for using sockets instead makes way more sense.
I don’t have a good way of doing remote pairing with tmux: I have to start a seperate tmux with a particular socket location and the connecting user has to know that location to connect to my session.
I would love sane, built-in support for granting particular users access to my tmux socket (making /tmp/tmux-$(id -u)/foo world writiable) and that connection would only be able to view and write to the current window, not switch sessions or anything like that.
I do remote pairing with tmate at work, but I don’t know tmux very well, so it is a hassle. If there was a screenmate, I’d switch in a second, but I should probably just embrace tmux.
tmate is nice, but I switched to using wemux after I got tired of losing session state after changing networks or losing connectivity.
Does this actually support the same workflow as tmate? If so, I might be sold! A single bash script vs. a fork of tmux + patches, and another server component, etc, etc, is much nicer!
The workflow is different. Wemux itself doesn’t deal with remote access; it just makes sharing sessions between local users much easier. So I have a wemux user with a .bash_profile consisting of wemux pair; exit, for which I can control SSH authentication like any other user. I’ve come to prefer this to tmate’s workflow.
wemux pair; exit