4 cool terminal multiplexers

The Fedora OS is comfortable and easy for lots of users. It has a stunning desktop that makes it easy to get everyday tasks done. Under the hood is all the power of a Linux system, and the terminal is the easiest way for power users to harness it. By default terminals are simple and somewhat limited. However, a terminal multiplexer allows you to turn your terminal into an even more incredible powerhouse. This article shows off some popular terminal multiplexers and how to install them.

Why would you want to use one? Well, for one thing, it lets you logout of your system while leaving your terminal session undisturbed. It’s incredibly useful to logout of your console, secure it, travel somewhere else, then remotely login with SSH and continue where you left off. Here are some utilities to check out.

One of the oldest and most well-known terminal multiplexers is screen. However, because the code is no longer maintained, this article focuses on more recent apps. (“Recent” is relative — some of these have been around for years!)

Tmux

The tmux utility is one of the most widely used replacements for screen. It has a highly configurable interface. You can program tmux to start up specific kinds of sessions based on your needs. You’ll find a lot more about tmux in this article published earlier:

Already a tmux user? You might like this additional article on making your tmux sessions more effective.

To install tmux, use the sudo command along with dnf, since you’re probably in a terminal already:

$ sudo dnf install tmux

To start learning, run the tmux command. A single pane window starts with your default shell. Tmux uses a modifier key to signal that a command is coming next. This key is Ctrl+B by default. If you enter Ctrl+B, C you’ll create a new window with a shell in it.

Here’s a hint: Use Ctrl+B, ? to enter a help mode that lists all the keys you can use. To keep things simple, look for the lines starting with bind-key -T prefix at first. These are keys you can use right after the modifier key to configure your tmux session. You can hit Ctrl+C to exit the help mode back to tmux.

To completely exit tmux, use the standard exit command or Ctrl+D keystroke to exit all the shells.

Dvtm

You might have recently seen the Magazine article on dwm, a dynamic window manager. Like dwm, dvtm is for tiling window management — but in a terminal. It’s designed to adhere to the legacy UNIX philosophy of “do one thing well” — in this case managing windows in a terminal.

Installing dvtm is easy as well. However, if you want the logout functionality mentioned earlier, you’ll also need the abduco package which handles session management for dvtm.

$ sudo dnf install dvtm abduco

The dvtm utility has many keystrokes already mapped to allow you to manage windows in the terminal. By default, it uses Ctrl+G as its modifier key. This keystroke tells dvtm that the following character is going to be a command it should process. For instance, Ctrl+G, C creates a new window and Ctrl+G, X removes it.

For more information on using dvtm, check out the dvtm home page which includes numerous tips and get-started information.

Byobu

While byobu isn’t truly a multiplexer on its own — it wraps tmux or even the older screen to add functions — it’s worth covering here too. Byobu makes terminal multiplexers better for novices, by adding a help menu and window tabs that are slightly easier to navigate.

Of course it’s available in the Fedora repos as well. To install, use this command:

$ sudo dnf install byobu

By default the byobu command runs screen underneath, so you might want to run byobu-tmux to wrap tmux instead. You can then use the F9 key to open up a help menu for more information to help you get started.

Mtm

The mtm utility is one of the smallest multiplexers you’ll find. In fact, it’s only about 1000 lines of code! You might find it helpful if you’re in a limited environment such as old hardware, a minimal container, and so forth. To get started, you’ll need a couple packages.

$ sudo dnf install git ncurses-devel make gcc

Then clone the repository where mtm lives:

$ git clone https://github.com/deadpixi/mtm.git

Change directory into the mtm folder and build the program:

$ make

You might receive a few warnings, but when you’re done, you’ll have the very small mtm utility. Run it with this command:

$ ./mtm

You can find all the documentation for the utility on its GitHub page.

These are just some of the terminal multiplexers out there. Got one you’d like to recommend? Leave a comment below with your tips and enjoy building windows in your terminal!


Photo by Michael on Unsplash.

Fedora Project community

13 Comments

  1. murph

    I’m pretty sure that screen is still actively maintained. It doesn’t need to be included, (That’s up to you) but no reason to say that it’s not being maintained. http://git.savannah.gnu.org/cgit/screen.git/log/

  2. dac.override

    “By default terminals are simple and somewhat limited”

    Not TermySequence

    TermySequence is:

    A set of design goals and a protocol specification for a multiplexing terminal emulator server with many features.
    A server implementation written in cross-platform, multithreaded C++ with minimal dependencies.
    A Qt-based client implementation with its own set of features, including a plugin system using an embedded Chrome V8 Javascript engine.
    A terminal emulation system with a focus on connectivity, productivity, and collaboration.
    Free software, licensed under GPLv2.

    TermySequence is packaged for:

    Fedora 28+ via the official repositories (instructions)

    https://termysequence.io/

    • TermySequence looks really cool, would you be interested in writing an article about it for the Fedora Magazine ?

      • dac.override

        I am not such a write, but i can give you a run-down here and maybe someone else can write a nice article:

        Someone once said: “By default terminals are simple and somewhat limited”.
        Many of us spend significant time using terminal emulators. Yet A lot of us want it to be fast and light. Why skim on something as
        important as a terminal emulator?

        If youre familiar with terminal multiplexers then you probably know some of their limitations. Take for example nesting.
        You open a terminal emulator locally, then execute a terminal multiplexer. Then you use ssh to connect to a remote machine and either
        run another terminal multiplexer there or attach to an existing one. Now you have a terminal multiplexer running in another terminal multiplexer.
        That is where things get confusing because your usual keyboard shortcuts only work for the local instance. You would use different shortcuts
        to control the remote instance.

        On top of that, sometimes you need to read or edit a remote file. Things would get even more complicated there because for example if it is a
        pdf then you might for example use

        ssh -X

        and then run

        apvlv file

        on the remote. There are two considerations there: 1. you need a display
        server on the remote, 2. youre running a remote instance of apvlv. Otherwise you might use fusermount and/or sshfs to mount the remote pdf
        locally so that you can open it with your local apvlv instance. Eitherway, not ideal.

        Enter TermySequence:

        So why is there no solution for these issues? Why can’t we have all this integrated into a terminal emulator?
        TermySequence is a rather heavy weight solution compared to say using a “simple” terminal emulator, ssh, fusermount, and a terminal multiplexer.
        It integrates these features in a neat new way and hides some of the dirty details. It is basically a client and server model.

        You can either just have a termy-server running on a remote headless system and connect to that with a local termy-qt client and/or have both
        server and client. You connect from the client to server instances, locally and remote. When you close the client, your work done in terminals
        running on the server instances is not lost and you can reattach later, just like terminal multiplexers. You can also connect from one server
        instance to another, effectively chaining connections.

        There is a file manager that can be used to open remote files with local applications seemingly transparently. You can do collaboration
        easily by sharing termy-server instances. Either take ownership of your own terminals or allow remote input. You can attach avatars so that
        people can “put a face on a terminal”.

        TermyQT is a modern terminal emulator, so you get emoji, inline images, a plugin framework and a lot of other features. Too many to
        address here.

  3. bachradsusi

    My favorite multiplexer is a combination of emacs-nox in daemon mode, emacslient and (ansi-term “/usr/bin/zsh”)

  4. Luciano

    I understand the need to multiplex terminal window…
    But I don’t really understand what these programs provide in addition to the features of, say, Konsole. I can have tabs, split windows… I can send the same input to multiple subwindows.
    What can these provide that I cannot already do with Konsole?
    Unless the terminal session is in a non graphical environment, of course, but that’s not common for me.

    • @Luciano: That’s exactly what these multiplexers are for. Having a multiplexed session available via either GUI or console is very useful. There are also plenty of situations where, say, passing graphical information over an SSH tunnel is unwanted. Glad you don’t need it, but many people do. 🙂

  5. epii

    Check out terminator, available in Debina, Ubuntu, Linux Mint, etc. Easy to setup, use and very configurable.

    • far2fish

      I use terminator as my preferred terminal in Fedora 29.

  6. Cata

    PAC Manager is my favorite, is more a connection manager but is useful when you have many servers to take care.

  7. Thomas Stephen Lee

    Hi,

    A bug I ran into.

    https://bugzilla.redhat.com/show_bug.cgi?id=1480460

    Affects byobu

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions