(Apologies if this threads incorrectly: I'm doing my best to deal with the fact I got this email as part of a Google Groups digest, and not an original email. Hope I got it right!)
Tmux and screen are both excellent and viable options for tty multiplexing. There are legitimate reasons to use either over the other, depending on what your needs are, but I suspect that a majority of users won't particularly need the advantages either one has over the other. I'm an ex-screen user/developer who moved to tmux as soon as I discovered it. The three primary motivations for me were: - As a F/LOSS hacker and dev, I'd spent some time hacking GNU screen internals. Actually, I spent a _very_ brief stint as a co-maintainer. The code is old, and has its share of surprises. It (ab)uses the preprocessor a fair bit, and lots of things "know about" lots of other things (inadequate encapsulation). I quickly found that adding features and making fixes to screen was painstaking, due to how careful I had to be to ensure that I'm not breaking 10 other things when I make a change. As soon as I saw how comparatively cleaner tmux's (much newer) codebase was, I was ready to jump ship. - I play with a lot of text in a variety of languages, so unicode support is important to me. Tmux's unicode support is (or at least was at the time) better integrated, particularly when it comes to inclusion in the status bar. Both tmux and screen, at the time, had a few issues regarding wide-character (e.g., East Asian language) support, but tmux's were easy to help fix (and I haven't noticed them rebreaking anytime recently) - I found tmux's use of command-line scriptability to be a fresh breath of air, in comparison to screen's scripting support. At the time, screen had historically only supported scripting via some extremely kludgey escape sequences, which required a fair amount of hackery to use, and in any case had to be explicitly enabled. It was probably marginally less safe than tmux's CLI method, too. Scripting support in the form of language bindings, had JUST been added as well (can't remember which language), and since that time my understanding is that they've added support for other languages. But tmux's shell-scriptable CLI approach feels much simpler (you can invoke the shell from any language, after all), and much more Unix-y in philosophy. I certainly enjoy it, at any rate. Clearly, the first two of these considerations are not going to be very important to most people. I have no idea whether screen's current unicode support has been improved in the last 7 years, but I know that for most purposes it was more than adequate for most people, probably even East Asian users. The only serious difference that even comes to mind was unicode support in the status bar, and I wouldn't be surprised if that's now supported in screen. The third consideration is likely a matter of personal preference, and if you don't find it useful to script your terminal muxer, you won't care in any case. One could argue that, while the first consideration is only directly of interest to people who plan to hack around in screen or tmux internals, ease of modification for developers may well translate into benefits for non-dev users, too. Still, a pretty minor consideration. . Screen has some legacy features that some users find very useful today, that are not a part of tmux. I'm not 100% sure it's still in there, but screen had serial communications support, meaning you could use it directly as your serial terminal, controlling baud rate, and supporting Z-modem downloads. That's pretty much useless to most people using modern computer systems, but likely vital to folks on older setups. If it is still supported by screen upstream, I think it's often not baked-in by default for most distributions (i.e., maintainers opt to leave it out of their build.) Screen's "ligature" system for typing non-latin characters is also very useful to some. Particularly if you're using screen on a naked tty, and not via a window manager or desktop system that already provides convenient means for entering foreign characters. But I'd hazard that most people do use such systems, and likely don't need those ligatures. Both of those features, to me, feel a bit "scope/feature creep". But the reality is that both of them also made a great deal of sense to build-in at the time that screen was originally written. . Tmux and screen have other differences; most of them, to me, amount to differences in how they think about and work with things, and not actual differences in functionality. For instance, all tmux sessions are (by default) handled by a single server process. If some glitch occurs and tmux hangs or crashes, all those sessions come down together. However, there's nothing preventing one from invoking separate servers instead of sessions, thus reconciling the difference. It's not necessarily the typical way of using tmux, but it works reliably and then it's not different from screen. On the flip side, this default behavior enables a tmux client to actually switch which session it's viewing on the fly, which screen can't do (nor individual tmux servers). tmux tends to think in terms of "panes", and every window has its own layout associated, and switching "windows" switches layouts. IIRC (big "if"), screen windows are analagous to tmux panes, and switching a "window" just changes that inner frame, leaving the others on the screen unchanged. Instead, it has a separate concept of "layouts" you can switch between, which was a newish feature around 2009 or so (IIRC). Both of these paradigms offer basically all the same functionality, but the thought process is different. Hope that helps! -mjc -- 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 [email protected]. To post to this group, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
