The other beginner tip I would give that's not in the original article is the command:
I use every feature it offers: scroll back, copy buffers, window splitting/management, different sessions for different projects, etc. I do a lot of work on different servers (it’s not uncommon for me to be connected to 4 different servers at once) and having tmux on all of them means I can always pick up right where I left off. If I’m starting a long build on a Friday afternoon, no problem: start it in the remote tmux session and simply detach from tmux and log off. When I come back on Monday morning, I just SSH back in, reattach to the tmux server, and it’s like I never left.
Tmux has a steep learning curve for sure, but if you are a terminal user at all I cannot recommend it highly enough. It’s a game changer.
I think I found the session management / default pane arrangement tricky, and would forget the hotkeys after a week or two of not using it.
Developing the muscle memory definitely takes some work and no doubt it will feel awkward and unnatural at first. I would offer the same advice I would offer to someone getting started with Vim: don’t try to learn everything at once. Start with the basics, get comfortable, and over time you’ll learn more and more little tricks.
For example, start with just getting comfortable with creating new windows (prefix + c), splitting windows (prefix + % or prefix + “), moving between panes (prefix + arrow keys), and moving between windows (prefix + n and prefix + p). If you’re used to using the mouse, you can also enable mouse mode which will make the transition a bit easier (this allows you to select panes by clicking into them and using the scroll wheel to scroll within panes).
I know offering raw config files is kind of a trope and not always helpful, but here are mine  if you’re curious. I try to keep my config minimal and not too fancy, but I do override/change some defaults.
It is my own fault of blindly following someone's online configuration without truly understanding each line of the setup. I spent a whole day trying to recover my customized prefix and lost in pane vs window differences. Now my .tmux.conf only has 4 lines and I am done with over-customizations. It was unnecessary emergency when I was already behind on work. I don't think I will ever migrate the rest of the config.
On the other hand, who is using any linux-like OS on a daily basis and upgrades major software versions when they have work to do?
I usually only do full system upgrades (including essential software like tmux, vim and such) only when I know I have spare time in case there is things breaking, as 1 out of 10 times, something will break/be deprecated/have changes somehow.
But, thinking about it, none of this makes sense, and not sure why apt is mentioned at all, seems I misunderstood you?
So then I have to fix tmux instead of whatever it was I was doing the original upgrade for. As a daily linux user, your original point doesn't make much sense in this light, since upgrading is a part of work.
I like the fact that it is practical-minded, addressing topics likely to be of interest to newcomers. An example is its explanation of rebinding the % and " window-split keys so that the new panes will share the parent directory. Sure, that's a small convenience, but small things add up.
Screen may have caught up a bit since then, but tmux seems to have a more active community and generally faster pace of development.
But I couldn’t tell you now, without some digging, whether screen supports all these features today, or if it’s perhaps even better than tmux.
If you like GNU Screen, continue using that, they are very similar tools. I’m a
long term user of both, using both for a while, and now only using Tmux
exclusively. I need a terminal multiplexer, since I often use my main computer
The main advantage of GNU Screen for me was it was slightly more robust, it
crashed less for me. While both are pretty stable. I can run both for weeks
at a time, and not have any issues. Though, I’ve heard others report the
opposite about stability between the two tools.
Tmux has some advantages for me:
- Tmux is scriptable. You can run tmux commands to query and set the state
of Tmux. It is possible to pipe and process those results. There is some
thought behind the commands, that make them consistent and orthogonal.
Screen never really could not do much beyond listing the available
- This has made it easy for 3rd party developers to create Tmux plugins, adding some useful features.
- I think GNU Screen can now do split screens, but I feel it is easier to do
in Tmux. Many times I have a monitor with full a window terminal, and Tmux makes
it easy to split that up into smaller independent terminal panes.
- GNU Screen development had pretty much stalled for years. Tmux is being
actively developed. Outside developers are welcome to make contributions.
- The lead Tmux developer, Nicholas Marriot, is actively engaged with
users. He responds to bug reports, helping track down bugs, and
collaborating with contributors.
- I believe GNU Screen development has started again, but to me it just
doesn’t have the same level of engagement from the developers.
- Tmux has regular releases, compared to Screen
- Tmux is more current with the latest ANSI/SGR/OSC codes, and has robust
unicode support. This hurt me most when I use a wide terminal (> 256
columns), and wanted to use the mouse, going past a certain column was
broken. There is a new encoding SGR 1006, and it didn’t work with GNU
Screen, but did with Tmux. GNU Screen picked this up in 2019, but Tmux
had it for years before. There are other codes for 24bit color, italics,
fancy underlines, etc that GNU Screen doesn’t support, but many modern
terminal emulators do. Even ITerm2 has Tmux support builtin. While I
generally don’t need these but if/when I do, Tmux just works, while GNU
Screen just ignores these codes.
On the other hand, tmux provided it out of the box, and had a vibrant dev community with frequent updates.
It looks like the dev situation for screen “reset” around 2014 with the 4.2.0 release, including vertical splits. And that’s great! But for a long time tmux was the future and screen very much the past.
By now it’s mostly force of habit, I suspect—but I’ve never looked back from tmux and I’m not sure there’s any reason I would (but by the same token no reason you should switch either).
Extensibility, plugins and more
Search in terminal for text
And there is a lot more, which I have not yet learnt.
See the tmux awesomelist for a better insight
Or is there a better tool for this?
Use-case is basically I want to stop all work-related resources at end of work day including docker containers, but restart them the following day. Ideally it would be as simple as tmux a -t work to get started again which would start necessary docker containers from a bunch of directories, and then tmux detach would kill the containers
You can write very simple scripts that perform the actions that you describe. It does not seem that there's a better tool than the shell, for this.
I use this one as I found it easier to set up, and a bit more intuitive to script. Also if you use python rather than ruby, it's easier to understand!
There are other solutions but I used this one for a while and liked it. Then stopped doing as much development at home (work is Windows) and haven't used it in a while. It's easy(ish) to create different configs for different needs. I basically had a Common Lisp IDE or a C++ IDE or whatever set of things I commonly used.
bind -T root M-h select-pane -L
The -T root does what you want, ie bind a key without a prefix. M-h is Alt-h, so change that to whatever you want of course.
I am a heavy Vim and tmux user, so if you’d like you can use my own config for inspiration:
After that maybe try to do same with AwesomeWM and that would be the ultimate navigation setup.
Without it, when your connection gets hung, you lose that session on a remote server and practically you can't get something done through unreliable connections like on a phone without session resurrection.
And if you had several panes open and want to continue working later, are people just resetting its state everytime they leave the remote terminal?
You only need several lines of config or use byobu to get it to work that way.
This is literally the reason that people use it. It can disconnect and reconnect to the same session. I have had a tmux session running remotely for over a year and I reconnect with it ever day with all my panes and windows still the way I left them.
I don't see how the default is never improving for a few decades.
Not a use case per se, but the issue I mentioned in GP is that if you detach from tmux session, accidentally or not, and you want to reattach to the session, you need an non-tmux terminal for that, since trying to attach from tmux causes it to complain that "sessions should be nested with care, unset $TMUX to force". Now you can bypass that by unsetting $TMUX, but it really doesn't work. And if your terminal automatically starts tmux you need to change its configuration when it happens or use another terminal or profile.
After a week or two of trying I settled on starting tmux manually after launching terminal (which is kitty these days).
I always get overwhelmed by how much it can do, so focus on a few useful features.
Definitely prefer it to "screen"
Make sure you use `tmux -CC` to launch
(Maybe that's less of a big deal for people who are already tmux experts...)
Scrollback, selection, search, and buffer piping are 10x more powerful than any terminal emulator's builtin selection/search/URL-detection that I've tried. With one keybind, I can interactively select Web URLs with the keyboard; with another, I can fuzzy-search both Web and non-Web URIs (including mailtos, gemini://, etc) with FZF. I can use a non-URL regex as well if I want.
I can also detach/reattach sessions, which is useful both with and without ssh.
You get all these features in any terminal emulator you use, including the virtual console (which doesn't normally even have scrollback).
If you build Tmux as a static binary, your favorite terminal emulator is just an rsync command away on any machine you use (assuming you're allowed to chmod +x a file).
And this is typically what I use on remote systems or even in local containers or VM for development unless the system is really constrained. Mouse and copy-paste integration with the local desktop then typically works out-of-the box.
Whenever I use a tiling wm, I don't use tmux. Otherwise, I do.
(I don't want to use custom keybindings either, cause I don't like straying from the defaults.)
That's about all you need to keep in your head to get a lot of power out of tmux.
Spend a couple hours some night editing someone else's public tmux config and it'll really pay off.
(FWIW, my capslock has been rebound to be ctrl, and I do ctrl-a as my tmux-mode key. Really recommend if you use a terminal a lot.)
As with all software, if you are used to the setup of an alternative program, it takes time to retrain your musclememory.
I use this instead of tmux, it allows me to split panes GUIy.
(*) - I still use Terminator, but only to provide tabs(tabless tabs in a fullscreen window with no borders) that I can easily switch between(Alt-#). I guess now that I'm comfortable with tmux I can probably drop Terminator entirely.
I feel naked without tmux. I naturally want to do various tmux actions. It's maybe like pinned vs unpinned browser tabs. If I have a terminal without tmux running, it feels like I'll close it soon, so I don't get attached, and it bugs me a bit the longer it's open.
I still use split windows inside vim and emacs as well. Some say it's silly or redundant, but they all work a bit differently and have their own functions. Emacs can scroll the "other window", vim has an extra clipboard.
I'm sure there's some terminal emulator that supports that...any recommendations/suggestions/configs?
BUT - it still has plenty of utility when working on remote machines. So, I still use it every day. I'm just not constantly working in it.
the executable file is read-only, so the OS loads only 1 copy of it into memory, which is shared by the 20 processes.