Hacker News Reader

Comment by emptysongglass | Hacker News Reader

I'm not sure I understand the use of tmux. Can someone explain why it's essential to their workflow and why it might end up being essential to mine?

View on HN

At any given time, I'm working on like 10 different projects. tmux lets me set up sessions for each of these projects, so that when I leave one and come back in a week, all the context is there (multiple windows, bash history, working directories I was in, etc)

Since I work with big biological data, most of my work takes place on our university cluster, which means my laptop is just a dumb terminal and all of the action takes place on the server. IME, tmux is especially powerful with coupled with mosh, which gives a persistent SSH connection. That means I can be in the middle of a project, close my laptop lid, go home, then later that evening, open my lid and everything is reconnected and just right there. Same if I reboot my laptop - one command to reconnect my terminal with mosh, and I'm back in the middle of my complicated multi-window project.

What happens when you press page up or down in tmux? Have you configured it to scroll page up & down? Or do you do that via Ctrl-B ] or whatever the magic incantation was?

That's right. You have a prefix that lets you use page up page down in any pane you've got currently selected.

Not parent but keybindings are fully configurable. For example to scroll up with Shift-Pgup:

    bind -n S-PPage copy-mode -u
    bind -T copy-mode S-PPage send -X page-up
    bind -T copy-mode S-NPage send -X page-down

The first line is a top-level binding to enter copy-mode and immediately scroll up one page. The other two add bindings within copy-mode so you can continue to scroll up or down with those keys.

I also have a small hack in my .zshrc to start scrolling up with `M-v` (like in Emacs) while at a shell prompt:

    tmuxup(){tmux copy-mode -u}
    zle -N tmuxup
    bindkey '^[v' tmuxup

I used to do all of this type of stuff to get my copy-paste to work in tmux but honestly it's still a pita. The alternative I started using recently (zellij[1]) has copy and paste, scrollback, dump scrollback to editor etc just working out of the box with no fancy configuration required and also has a much saner session management mechanic that also works right out of the box.

[1] https://zellij.dev/

When I used tmux I used to set Ctrl-PgUp/Down bindings to scroll the buffer.

Ctrl-B PgUp/PgDown enters scroll mode.

> Ctrl-B ] or whatever the magic incantation was

This is something tmux inherited from screen, but it from a quick test it looks like they didn't copy the whole thing? You use [ to enter this mode (it's actually for copying text, not just scrolling) and in screen use ] to exit without copying anything. Looks like tmux doesn't have ], at least by default?

I used to work on CECL and stress testing models for large banks and i used tmux similarly. Lots of scripts that would take like 6 hours to run.

Similar use case here, but in a biotech company.

Tmux provides a means multiplexing a single terminal window into multiple terminals, either full screen, or like a tiling window manager. It lets you organize and label these terminals and provides a very flexible keyboard interface to terminal management, including history scrollback, search, etc. I started using GNU Screen in the early 90s, and over the years I have developed a keyboard muscle memory for managing multiple terminals in this fashion that is completely independent from whatever terminal program I'm using. This allows me to utilize this keyboard muscle memory if I'm using iTerm2 on macOS, Windows Terminal, or Alacrity on Linux.

Many fancy terminal programs offer some subset of these multiplexing features (like tabs) and such, but in my experience none of them are as configurable or as feature rich as Tmux.

It's also very good if you're SSHing over an unreliable connection. The tmux terminal doesn't break when your connection does.

I use tmux, but as far as unreliable connections, I've found mosh[0] to be the best solution to the problem (when you have the ability to install it). It basically runs a background process on connection not tied to the session that your client will automatically reconnect to if the connection fails. I regularly close my laptop, travel between home and work, open it back up and the connection is available almost instantly.

[0] https://mosh.org/

Both together are even better... seamless persistence of your session across sleeps/connection lapses from mosh, and from tmux for everything else like switching client machines, a dead battery, a client's OS/terminal crashing, etc.

Absolutely. I personally prefer to use both together.

This is exactly the same reason I had in the 90s using tmux’s precursor, GNU screen. With dialup or crappy isdn, screen -R was always the first input after login

Have we gone from shitty connectivity to stable and then back to shitty?

I don't think so! But tmux is really useful for laptop scenarios, like when the laptop goes to sleep, or if you're working on a train and it goes through a tunnel with no network reception.

I still use screen, is tmux better?

By a decent measure, yes. It's screen plus modern QoL additions like multi-panels/windows/tabs and a giant pile more, and it's decades-stable so that's not like a "node framework of the week" pile of useful stuff that you'll have to rip out next month. It's very firmly established as a full screen successor.

For strictly "keep one thing running remotely" it's not much different (screen is entirely fine), but for "do work remotely" it's like comparing `cat` and `less`. One does what the other does and a heck of a lot more that is very useful when you need it. Sure, you can use grep, but having an integrated (reversible) incremental search is hard to truly replicate from the outside. Tmux is kinda on a similar level vs screen.

Personally fwiw: I almost exclusively use tmux with iterm's integration, so I don't have to learn basically any of it. I just get resumable terminal tabs and windows when I ssh anywhere, and they're still there months later when I go back. With that kind of setup it's just plain magic, a complete no-brainer, feels like what computing just obviously should be (even though it isn't). I've learned enough of the details around screen/tmux/etc to know that I'm glad to shove almost all of it over there and ignore it.

It's handy even if you just need to go from work to home to Starbucks or whatever. Doesn't have to be a poor connection as much as one that changes occasionally.

In a way - I use laptops that move around and go on/off, as well as VPNs which do the same, network-wise.

SSH fares poorly on mobile connections if you're traveling due to IPv4 roaming. Mosh solves that issue.

You can use shpool for this if you aren't using the other features.

Personally I find the small shell function below really helps my tmux workflow. Run it with no arguments and you'll get a list of available sessions. Run it with a session name and it will start the session if it doesn't exist or reattach if it does. If you're already in one tmux session, it will just switch over your client to that session.

The function below will also automatically detach other clients, but for me it's what I want since other clients are always just me on another machine, often with a different screen size.

    tm () {
        if [ -z $1 ]
        then
            tmux list-sessions
            return
        fi
        tmux detach -s $1 2> /dev/null
        if [ -n "${TMUX+1}" ]
        then
            tmux switch-client -t $1 2> /dev/null || tmux new-session -s $1
        else
            tmux attach-session -t $1 2> /dev/null || tmux new-session -s $1
        fi
    }

I have a better version (in the sense that it automatically names sessions after the current directory):

  if [ -z "$1" ]; then
    name="$(basename $PWD)"
    name="${name//\./-}"
  else
    name=$1
  fi

  tmux has -t "=$name" && tmux attach -t "$name" && exit

  tmux new-session -d -s "$name" -n shell

Better is subjective. This version has no way to easily list sessions. Depends on what you want :)

Saved terminal state. Multiple tabs. Can log off and come back and everything’s there. tmux and mosh are game changers, especially while tethering/roaming and switching networks.

Maybe one of the missing pieces here for anyone not terminal-fluent:

Normally, when you lose your ssh connection to another machine, it'll kill your scripts, drop all the output into /dev/null, and you can't get any of it back. Because that's how a remote terminal normally works.

So even brief connection issues are a major headache, much less known stuff like "close your laptop and resume after lunch".

Tmux gets you what you would expect instead from a "remote tab" thing. Stable, reconnectable, still exists when you're not connected, etc. There are other options of course (there always are), but tmux does it all and it's an industry standard.

That should be table stakes at this point; these features should be built into all conventional desktop terminal emulators. I shouldn't have to run a second, inferior text mode terminal emulator inside the terminal emulator app that ships with my preferred desktop environment (and deal with the conflicts/impedance mismatch that falls out of this pairing).

Pretty nuts that so many desktops and independent modern terminal emulators lag so far behind GNU Screen, which was first released in 1987.

Personally I'd much rather run that server-side. I use iTerm which has a lot of great features for session management, but I like being able to connect from any machine and keep the exact state I was in rather than having it tied to my local client.

I prefer tmux because I can run it on servers/remote machines too. It doesn't require X so runs perfectly and happily on headless machines. Can also be nested.

I'm all for adding those features to the terminal emulators, but it will never meet and certainly not exceed tmux in flexibility, power, portability, and compatiblity.

Hard disagree. I very much like my terminals thin and "stupid" (sixels, clickable links, speed, and workable CJK font/IME support are about the non-standard features I really want), leaving all the navigation to something like tmux/zellij/screen.

There are other features a desktop terminal emulator can not give you. And being able to maintain all the shortcuts and muscle memory across devices, servers, X11/Wayland, different DEs, and inside nested VNC or SSH sessions, more than compensates for "impedance mismatch" (curious what you're actually referring to here... Just putting a line in my shellrc to start a new tmux session unless the TMUX env var is already set makes it mostly seamless and you could do the same in terminal emulator conf if you dislike putting such things in your shell or profile).

Unix philosophy: I want my graphical terminal emulator to render my sessions on my display. The stuff happening inside should mostly not be its concern.

> I shouldn't have to

Good thing you don't have to, then. For casual users, emulators like Kitty, xfce-terminal and Konsole exist and are quite popular. Yeah, a batteries-included terminal emulator sounds more appropriate for you and probably the majority. For "niche" users like sysadmins and many power users, tmux is the table-stakes. There's no one-size-fits-all and not everything has to be for everyone.

> GNU Screen

Well, there's the topic of the thread...

As for me, I like the “do one thing well” philosophy — I don't want my terminal to manage multiple sub-‘windows’, because I already have a window manager that I like just fine thank you.

`tmux` is actually more than I want, because it interposes itself as a terminal emulator in its own right (hence, per the thread parent, requiring its own sixel support on top of the display terminal's) and use `dtach` instead: it's just a pass-through session holder. Something like `tmux` is necessary when you want to connect to a session from significantly different terminals (say, iTerm on a Mac and Konsole on *nix) but I don't do that.

> these features should be built into all conventional desktop terminal emulators.

Lennart, is that you? ;)

The first problem is that most of that is a result of how the remote computer handles the programs you were running. When your connection drops, all of them die immediately.

Second, terminals have state. That state must be synchronized between the program you are running on the remote computer and the terminal on your local computer, or the display will be garbled. Even something as trivial as the cursor position is important. If you disconnect, then your program prints something or moves the cursor, and then you reconnect, whatever it did has been lost and whatever it does next will not be correct. At best it will just be a few lines of lost output, but it could be output at the wrong position on the screen, resulting in a garbled display. Or the size of your screen could be different, again garbling it.

Worse, the remote side could send an escape sequence that changes the terminal’s character set. If your local terminal misses that, then the incoming text will be unreadable. Of course, with the spread of Unicode this has become quite rare. You are most likely to see the problem with programs that switch character sets to draw a UI or other artwork; the line–drawing characters would be printed using ordinary letters and numbers.

What you really want to run is not tmux but a program called mosh. mosh is a drop–in replacement for ssh. It runs on both your local computer and on the remote computer, and synchronizes the state of your terminal for you. The remote end maintains a representation of the local state of the terminal, and visa versa. If you lose your connection, mosh only needs to copy the remote state to the local terminal to resume the session correctly. The other cool trick is that mosh uses a UDP connection instead of TCP. This combined with the encryption it uses allows it to seamlessly resume your session even if your IP address changes suddenly. It also keeps your session alive even if the UDP packets from your local machine stop arriving. If you suddenly close the lid of your laptop, suspending it, it will patiently wait for you to open the lid again and seamlessly reconnect.

Mosh is a great tool but you’re thinking of tmux like a client side tool when in fact, like Mosh, you can run tmux server side and have it manage all of that annoying state you described earlier.

There’s definitely overlap in features between tmux and mosh but it’s better to think of them as solving different problems. Mosh is for working on laggy or unstable network connections. Whereas tmux is more like a terminal based tiling window manager.

At the end of the day there are as many good reasons to use tmux as there are good reasons not to. Like most things terminal based, it’s just a matter of personal preference

I didn’t say that it wasn’t. I was responding to the notion that “these features should be built into all conventional desktop terminal emulators.” There are reasons why it cannot just be built–in to the terminal emulator, and the best we can do currently is just to run some program like mosh or tmux on the remote side so that the terminal state is maintained correctly.

I suppose the terminal emulator could be more helpful though. For example, if you have a terminal emulator with local tabs/panes/splits/whatever, maybe it should orchestrate the process of connecting (or reconnecting) to the remote server. If I create a new tab or split the current window, it could connect automatically to the server for me. If it is connecting via mosh, then the terminal state in each of my tabs/windows/panes will be maintained correctly.

Anyone here who can answer this as well in the context of local work on a Mac? I manually use tmux when sshing into servers but usually that’s one session split in two and that’s it.

Locally I use iterm2 with a single hotkey window but multiple tabs with one per project and then up to 8 panes per tab. These stay open for many months until the inevitable restart for system updates. I feel like I have pretty good persistent terminals this way.

But would there be any benefit for me using tmux locally? I know that iterm2 has some kind of integration with it but I‘ve not tried that

I don't use tmux but I use screen which AFAIK is the same basic functionality on my Mac. I use it to run long lasting software during development, so the frontend and backend of the service I'm developing for example, since they have hot-reload.

It's not _necessary_ but it's nice knowing I can close my terminals without worrying of having to wait for another 10m build because I like to keep my open windows to a minimum.

I think it's really down to how you use your computer more than a real need.

> These (tabs and panes) stay open for many months until the inevitable restart for system updates.

And iTerm won't have a way to restore them, right? The `tmux resurrect` plugin can save and restore all your sessions, even after restarts. At the moment I have 45 tmux sessions running and I'm not worried in the slightest about not being able to pick up exactly where I was for every project.

Also, tmux is a nice way to "bury" your "windows." Hiding an iTerm window can only be done by covering something with it or minimizing it, but a tmux session can be detached from/attached to at will, and when you're detached it doesn't add cruft to your window management.

I use tmux basically the same way but prefer tmux sessions because I find tabs hard to navigate reliably.

With tmux I can assign a name to each session, list all sessions, and have keyboard shortcuts to take me to a specific session or create it if it doesn't already exist. <leader>+J always opens projectfoo, <leader>+K projectbar, etc.

With tabs you need to know which tab contains what and what order everything is in.

I like tmux for keeping a remote session open but I don't use it for my local machine. On my local machine the only thing it would really buy me are tabs/split panes, and iTerm does those things natively and far better than tmux does.

Aside from tabs/panes/persistence already mentioned, it serves as a portable, programmable layer that will work anywhere, whether on the client or server side. I set up my key bindings once and now they work over SSH from Windows, local terminal emulator, on a Linux framebuffer console or even through a serial port. While I do use a tiling/tabbing window manager, tmux is just really good at what it does so I still keep using it for my terminals.

It provides all of the useful functionality of a window manager (hosting multiple terminals) but you can run it in a terminal.

A use case I haven't seen mentioned - from skimming the comments, is that multiple users can connect to the same tmux session.

It does a good job at scaling the session to fit the size of each client's terminal window and has multiple scaling options available.

In my experience it works way better than for instance terminal sharing in VS Code.

Plenty of great use cases have already been pointed out, but what I also love is that sometimes I get carried away and use the close window keybind on the wrong terminal, with tmux set to create a new session when the terminal is launched (which isn't closed unless all shells in the sessions have excited) I just use a keybind to spawn a terminal attached to any unattached sessions and never again have to recreate 10 different panes in different working directories on different windows

Also let's my colleagues monitor my builds on our shared server pretty easily and it's better than screen sharing

I find the split screen capability very useful for terminal use, but i'm only a more basic user

tmux + vim with some plugins is a really good developer experience, it makes it really easy to leverage command line tools

why would you want browser tabs?

lots of good answers already. my tldr: it's a terminal-agnostic tool to split a window vertically or horizontally so you have multiple shell sessions on the same screen (and can move between them). Lots of other great reasons too but that's the major one IMHO.

Reply on news.ycombinator.com