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 of 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 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.

Now that we have used abduco for its pedagogic clarity, let us do what everyone else does, and ignore it in favour of the slightly more confusing tmux, which is well documented a supported and ubiquitous and thus has great practical advantages over its ideologically and pedagogically purer cousin.


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 of the 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 controversial and does not seem supported widely across other terminal emulators.

Here are some intros to tmux: 0 1, 2 and a cheat sheet. Terminology is confusing. 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

Scrolling, mousing

Once I had used tmux for a while I discovered I wished to do backwards scrolling. There are various keyboard shortcuts, and a mouse mode enabling scrolling (set -g mouse on in ~.tmux.conf, or Ctrl-b: set mouse on if I forgot to create the config file). tmux mouse mode is not great IMO. It tries to be way too clever. Sometimes it scrolls back through command history, which is downright evil even for someone like me who does not have the traditional hacker distrust of mousing. Probably there is some keyboard shortcut which causes the mouse scrolling to turn evil, no idea which one; I just want this thing to do its best to pretend to be the normal terminal and not try to do clever shit at me.

Mouse mode breaks copy-paste in that it only copy-pastes into a tmux internal buffer, not into the global clipboard. I am sure this feature suits someone out there, but not me because I also use non-terminal apps, and also use tmux only for remote control. The workarounds listed at that link do not seem to work on remote terminals. Anyway, shift clicking works around tmux. Possibly tmux-plugins/tmux-yank helps.

Other brokenness

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 (e.g. 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. HTM is an in-progress (?) terminal multiplexer standard. 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 rather than in a concrete actionable sense for someone like me. I think the documentation is this source code snippet?? 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.

Wez’s Terminal Emulator seems to support multiplexing. The standard it uses, if any, is not clear to me.

No comments yet. Why not leave one?

GitHub-flavored Markdown & a sane subset of HTML is supported.