Terminal session management and multiplexing

Disentangling the programs you are running from the terminal you launched them in, for recombining and tweaking. Typically one encounters this concept via tmux or the rather ancient screen, which do a lot of stuff at once, making it harder to explain. The convenience in is case might be outweighed by the confusion. It was for me. For example, it seems easy to confuse terminal session management with window management-plus-terminal emulators which is rather a different thing. tmux, for example, is:

  1. session management (for me, the most important thing), and
  2. keeping a nice, tidy-looking virtual interactive terminal to handle the input and output in that session and switching between sessions

The combination of these things is called a terminal multiplexer and we think about it as a way of multiplexing several terminal sessions into one network session, which is what people usually pitch to you. For me the idea of temporarily detaching processes from the launching terminal and then resuming control of them later is the killer feature. Multiple terminals and such are a side effect that I rarely use, which means that a lot fo the breathless tutorials focus on features I do not need.

These concerns are nicely separated in abduco, whose architecture is much clearer.


abduco is a tool which does strictly #1.

abduco provides session management i.e. it allows programs to be run independently from their controlling terminal. That is programs can be detached - run in the background - and then later reattached.

i.e. after I get booted off the server running my very slow job I can get back online and check on its progress later without anything going south because of my network embarrassment. However, if I am running some interactive process I might want that session to contain a nice virtual terminal which keeps track of the state of my screen and IO and all that stuff. dvtm is the twin to abduco that provides such niceties as clean and re-usable screen state.


tmux is functionally a combination of abduco and dvtm. On one hand it is easy because it is so popular and thus documented everywhere, and installed most places. On the other, it is confusing and has weird terminology, so you need all that documentation to work out what you just did. There is a comparison on slant ofthe tmux and abduco ecosystems.

A neat feature of tmux is that it has a magical integration with iterm2 on macOS in “control centre” mode, which makes everything intuitive by recycling the terminal GUI for handling session management. However, this is is controversial.

Here are some intros to tmux: 0 1, 2 and a cheat sheet tl;dr: It creates “sessions” which seem to be connections to a host, which contain “windows”, which are virtual terminals within that session. Both these persist if you log in or out.

World’s shortest introduction:

tmux ls  # list sessions
tmux attach -t 0  # resume a session
Create new windows
Ctrl-b c
Previous/next window
Ctrl-b p/C-b n

Once I had used tmux for a while I discovered I wished to do backwards scrolling. There are various keyboard shortcuts, and a mouse scroll mode. If the mouse scroll mode causes things to break after quitting tmux, and now clicking on the window causes this kind of crap: 0;38;15M 0;38;15m 0;60;12M0;60;12m0;56;14M0;56;14m0;56;14M0;56;14m0;54;13M0;54;13m0;54;13M0;54;13m… eek! Running reset puts things right in some circumstances. Other times (in hyper) reloading the terminal from the app window is necessary (Ctrl-Shift-R).

There are various other tools in the ecosystem, e.g. tmuxinator is a config tool for tmux.


Byobu is a GPLv3 open source text-based window manager and terminal multiplexer.… Byobu now includes an enhanced profiles, convenient keybindings, configuration utilities, and toggle-able system status notifications for both the GNU Screen window manager and the more modern Tmux terminal multiplexer, and works on most Linux, BSD, and Mac distributions.

Dirk Eddelebuttel points out

  • byobu uses (by default) one socket
  • you can designate a particular socket
  • and share ‘write’ permission with another users
  • and BAM you have multi-session multi-user work
  • for any application that can run a terminal

Question: since tmux can already work over named sockets, can tmux do this without special treatment from byobu?


mtm is an ultra-minimalist tmux replacement. I have not worked out which of the various features discussed here it implements.

Headless Terminal Multiplexer

As far as I can tell there is some kind of standardisation battle being waged. There is a terminal multiplexer standard being devised called HTM. Eternal Terminal and possibly hyper and possibly microsoft terminal may at some point support it. It is supposed to be more open than tmux’s control mode, although the documentation does not seem easier to locate, so it must be considered in more open in some abstract moral sense that does not necessarily have a concrete impact on outsiders. If HTM were to make progress, there would be a system for integrating various session managers/multiplexers into the GUI of the hosting terminal emulator in a cross-platform and mutually compatible way. This sounds nice I suppose but not nice enough to wander into a poorly explained standards quagmire of fringe technologies. I will not complain if this technology materialises and I am blessed with the chance to free-ride upon the efforts of others by using it.