Hacker News new | past | comments | ask | show | jobs | submit login
Get Started with Tmux (sunainapai.in)
220 points by susam 7 days ago | hide | past | favorite | 92 comments





The article covers the basics. Once you are ready to go beyond that, I would recommend exploring customisations, which are well covered by Awesome Tmux: https://github.com/rothgar/awesome-tmux

The other beginner tip I would give that's not in the original article is the command:

    set mouse
Doing so will toggle mouse mode. This means that there are a whole class of commands you don't have to remember as you get a feel for it. For example, highlight mode, scrolling, switching windows/panes.

Agreed, mouse mode plus zoom are two huge productivity boosters. Zoom is crtl-b ctrl-z and makes a console full screen.

Wow! This should be in the first paragraph of the man page. Thanks for this tip

Tmux is easily one of my all time favorite and most used tools, behind (maybe) only Vim/Neovim.

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.


Could you recommend any good articles? I've dabbled and enjoyed it but it never stuck with me.

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.


When I started out with tmux (and I echo the parent comment’s sentiment about it being a core piece of my workflow) I found https://pragprog.com/titles/bhtmux2/tmux-2/ to be extremely useful. It’s very brief and digestible, and sets you up to make any further customizations you want.

I’m sure I must have read a few articles many years ago when I first started using tmux, but I can’t remember what they are now and I wouldn’t be able to provide you anything that you wouldn’t just find on a simple search. Maybe I will sit down and write one so that I can offer something if this ever comes up again.

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 [1] if you’re curious. I try to keep my config minimal and not too fancy, but I do override/change some defaults.

[1]: https://git.sr.ht/~gpanders/dotfiles/tree/master/item/.confi...


Nice little tidbit about searching from normal mode, I'll be sure to copy that into my own .tmux.conf!

For me, just keeping my session active in case of a disconnect is worth it, especially when using SSH on a mobile.

Somewhat related, but I am still recovering from the aftermath of the 2.8 to 2.9+ migration https://github.com/tmux/tmux/issues/1689

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.


It was a bit annoying -fg -bg -attr into single config lines, I really wish they either supported backward compatibility or at the very least did provided an automated conversion. It was a pretty straight forward operation that could easily be automated.

Yep. The devs make random breaking changes all the time. They don't have any issue with doing it since they post breaking changes ahead of time.. but who actually watches for these things? It's super frustrating

> but who actually watches for these things

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.


Upgrade time often happens when new features are needed for some project. So, yeah, it gets in the way of work ;)

What kind of projects do you work on where new features to tmux are needed/required? Or put the other way around, what features in tmux were absolutely required for you to complete a project?

...apt-get upgrade, friend.

[flagged]


Hm. That's not what apt-get upgrade does. Can't tell if you're trolling, but I digress.

Sorry, I'm not following along at all but don't think it matters anymore. I got the impression that you are working on `apt`, and you're using `tmux` in some way when you're are working on `apt`. So when `tmux` releases a new change, you're unable to keep working on `apt` until X.

But, thinking about it, none of this makes sense, and not sure why apt is mentioned at all, seems I misunderstood you?


My point was that running `apt-get upgrade` is used in the process of installing packages besides tmux. For example some random postgres extension for something I'm working on, plus its respective dependencies. That process often needs a blanket `apt-get upgrade`, and very occasionally that installs a new version of tmux which isn't compatible with the old version's configuration file, breaking it in ugly ways.

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 don't think posting ahead of time justifies it. Unless there are clear reason for a breaking change, having some code to parse old config into new one, or at the very least convert the first time an old config is seen, is pretty trivial compare to the amount of time wasted by every single users manually converting their config.

Beyond that, tmux is (for me and probably many others) critical software used constantly when SSH'ing into many different boxes. Different boxes running different versions of tmux. Making it impossible to share one config file everywhere - you either need to have multiple config files for each version or simply drop any custom config that isn't cross-version compatible.

This is a clear and well-paced introduction to tmux. I've bookmarked it, so I can share it with others who ask why I use tmux.

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.


I have been a big fan of GNU screen for many years. What makes Tmux better?

When I made the switch from screen several years back, tmux didn't need a patched version to support vertical splits, which was nice. Other things included better support for scripting, nicer configuration, and better mouse support and scrollback behavior by default.

Screen may have caught up a bit since then, but tmux seems to have a more active community and generally faster pace of development.


Fundamentally they do the same thing. TMUX has a nice status bar, it's easier to play around with windows and it's got 256 colours support, as far as I'm aware. But really the difference is in TMUX having a dedicated community while GNU screen is just another GNU utility.

I used to use the Screen as a terminal multiplexer, but for the last 3 years, I have really only used Tmux. It is not better or worse. It's just different :)

I usually choose Tmux over GNU Screen because it seems more intuitive to use IMO, but I still choose Screen for some cases like connecting to serial consoles.

I started using tmux several years ago because it had better script support than screen did, at that time. I also liked the session/pane/window handling better (customization made a lot more sense to me, as a vim user), it supported some plugins that I really liked, and the ability to sync panes was a cool feature that came in handy sometimes (grepping logs for load-balanced applications), but I honestly rarely used.

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.


I'm sure tmux is great. But I've never seen the need to change. I'd happily read an article that shows me the benefits of changing.

Here's my take, most of which is in other comments:

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 via ssh.

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
    sessions.
     - 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.
While both are capable and usable, there are a lot of details that make Tmux better to me.

Screen is fantastic. Yet tmux btought us the future.

This does not really answer the question. What's so futuristic about tmux, specifically?

When I started using tmux, screen development was stagnant, and basic features (vertical splits, for me) weren’t available natively—a patch was required to enable it.

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


yep... I moved to Tmux specifically for vertical splits. No reason to flip back when they added them to screen years later

All of screen's functionality plus:

Multiple windows

Multiple panes

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


I always compare using tmux to learning touch typing, it's something you do once (by investing a bit of time to learn it) and reap the benefits for decades to come.

I would like to do the following: - Start work day, type a command to create a tmux session which would create x windows, dropping me specifically in directories that I specify in some config file - I would like to have scripts that are run for four scenarios a) on creation of the tmux session, re-attach to the tmux session, detatch from tmux session, destroy tmux session.

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


Look into tmux-resurrect[0]. It allows you to save and restore tmux sessions, and an accept-list of running processes within those sessions. Ideally, you'd get the tmux session into the state you want re: windows, CWDs, running processes, etc., save it, and then restore from that session in the future.

[0] https://github.com/tmux-plugins/tmux-resurrect


this plugin has been a godsend for me, since I like to have many sessions open, and I can resume my setup exactly how I left it in each and everyone of them, at any time.

Can we have tmux inside tmux, and still benefit from the session resume [and the sessions-in-session resume, of course]?

You might find tmuxinator (https://github.com/tmuxinator/tmuxinator) helpful. It doesn't do everything you describe, but I use it to spin up sessions configured per project.

> Or is there a better tool for this?

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.


There are tons of examples on how to do this in the shell. Here is some inspiration: https://stackoverflow.com/questions/54954177/how-to-write-a-...

Very similar to tmuxinator, but in python:

https://github.com/tmux-python/tmuxp

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!


tmuxinator

https://github.com/tmuxinator/tmuxinator

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.


Is there a good starter config for tmux for Vim keybinding users? I want to start tmux and want to use my AwesomeWM keybindings for switching the panes without a leader key. In general I want a migration without learning a lot of new keybindings.

Try this in your tmux.conf:

    bind -T root M-h select-pane -L
(I’m typing this from my phone from memory, so bear with me if there are minor mistakes.)

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:

https://git.sr.ht/~gpanders/dotfiles/tree/master/item/.confi...


Try the defaults until you get the basics. Look at the help file what you can do and what you need. After that you may want to implement seamless navigation between tmux panes and vim splits[0]. It really isn't a must but hey, it is very convenient for starters since they don't have any muscle memory for switching different splits.

After that maybe try to do same with AwesomeWM and that would be the ultimate navigation setup.

[0] https://github.com/christoomey/vim-tmux-navigator


I don't know how by default, login shells aren't invoked through tmux in 2021.

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.


> are people just resetting its state everytime they leave the remote terminal?

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.


It's a really terrible experience for a new terminal user where the color theme is black/white, fonts are very small and bash comes with minimal config and sessions are lost on disconnect.

I don't see how the default is never improving for a few decades.


I once added it to my bashrc or as the starting command of my terminal,but I quickly removed it since when configured so, if the session detached you have no easy way to open a non tmux terminal session to use for reattaching.

What use case that new panes can't fix that you need a non tmux session for?

A use case that is quite common for me is when I work on VM or remote machine, I usually run tmux on the remote, so I can open multiple panes/screens on the remote machine. Nested sessions are not fun, coming with two bottom bars and requiring you to press C-b twice for commands on the remote.

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


Since tmux is on the front page of hacker news, I thought I'd post one of my videos from a couple of years ago where I demoed some of its features.

I always get overwhelmed by how much it can do, so focus on a few useful features.

Definitely prefer it to "screen"

https://www.youtube.com/watch?v=JeOSpnT29go


if you are a mac user, iTerm2's native tmux integration is a game changer.

And if iTerm2 is a game changer for you, consider that it's written and maintained by one guy. Throw him a couple bucks!

https://www.patreon.com/gnachman/membership


I tried this once or twice but didn't understand what it was really accomplishing compared to just starting tmux normally. Mind me asking you to explain how you use it a little bit?

tmux panes and windows become native iTerm panes and windows. It allows you to open and split with the iTerm keyboard shortcuts you're used to ⌘N, ⌘T, ⌘D.

Make sure you use `tmux -CC` to launch

https://gitlab.com/gnachman/iterm2/-/wikis/TmuxIntegration


Scrolling just works natively, and you can use ^B inside vim.

(Maybe that's less of a big deal for people who are already tmux experts...)


I use iTerm integration over Eternal Terminal to my workstation all day. It’s great.

Wow, learned something new today. Very cool.

Here is my .tmux.conf complete with a quick tutorial if you have never use it before. I am also using Ctrl-A as the PREFIX as it is more ergonomic than the default of Ctrl-B.

https://github.com/jftuga/universe/blob/master/tmux.conf


since I use i3 I never bothered to learn tmux. If you use i3 is there any reason to ever use tmux on your local machine?

I use Sway and Tmux.

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


Well, you can also then statically compile a VNC server and tiling WM and get the whole remote desktop.

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.


As another user hinted, the difference is mainly about what's your top layer. If it is X11 or Wayland as you would on your desktop/laptop computer, than your tilling wm is the better place for that. If your top layer is a console session, as you would on a remote machine or a local VM, then Tmux is a godsend.

I'll sometimes use tmux as the backend for something like byobu (detaching and attaching to sessions mostly), but that's not really applicable to most local machine workflows.

No.

Whenever I use a tiling wm, I don't use tmux. Otherwise, I do.


I like the idea of using tmux, but the default keybindings are so awkward. Is there a good reason for the keybindings being that way?

(I don't want to use custom keybindings either, cause I don't like straying from the defaults.)


It's just a different philosophy. Ctrl-b turns on tmux mode. The only tricky ones to remember are " to create a horizontal split and % to create a vertical one, but you can remember them based on where these keys split your keyboard (& splits the keyboard down the middle as if you make a verticle split in tmux, " rests along the middle row of the keyboard like a horizontal split). Arrow keys to move about the panes is pretty intuitive. The rest of the commands are easy enough to remember: c to create a new window, n to go to the next window, p to go to the previous window, x to close a pane, & to close the window and all panes.

That's about all you need to keep in your head to get a lot of power out of tmux.


Everybody I've talked to who uses tmux has switched away from the default keybindings. I agree on straying away from defaults for most things since using custom configs makes it more difficult to work on random servers down the line. But.. tmux is an exception to that rule, especially since it only needs to be configured on one host, and none of the servers you might need to ssh into.

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


Same here for ctrl-a when I tried tmux. After coming from using screen a fair bit it felt so much natural.

as a dvorak user with caps bound to ctrl, ctrl-b is a lot easier to do then ctrl-a

Personally I think the default keybindings make a lot more sense then the ones from screen. Specially jumping to the start of the line, in screen, Ctrl-a a ... common ;P

As with all software, if you are used to the setup of an alternative program, it takes time to retrain your musclememory.


IIRC, tmux was originally developed inside of screen, so ctrl+b was chosen so it wouldn't conflict with ctrl+a

If you struggle with keybindings, you should try _byobu_, it has much saner key setup and shorter learning curve.

Also if you are a DE user check out https://gnunn1.github.io/tilix-web/

I use this instead of tmux, it allows me to split panes GUIy.


I used Terminator for a while and loved it, but eventually succumbed(*) to tmux. With tmux I get consistency across both local and remote connections. My remote connections have tiled shells and save state when my VPN goes down.

(*) - 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.


Love tmux. It was a game changer for me when training deep learning models. I really think this (or equivalents) should be a must learn

I've always wondered, doesn't tilling wms make tmux redundant for local development?

I've used tmux within a tiling wm for years. I never really understood this view that you don't need both, but it is common. I don't want a bunch of separate terminal windows. I lay out my tiles around having one main one, and then from there I split into tmux panes and windows. It feels neat and dense this way. I have a keybind to jump to my named terminal with tmux. It's easy to open a new tmux window with a few keypresses. It's easy to work with the scrollback. The layout stays consistent.

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.


You can write scripts to automatically open up tmux windows to certain directories/files/software arranged and named however you like. it can be handy to open an entire development workspace for a project with a single command. I'm not sure if other tools like i3 can do this.


I like having the familiar emacs keybindings to navigate the terminal, e.g. to be able to scroll quickly, search, and copy/paste without needing to take my hands off the keyboard.

I'm sure there's some terminal emulator that supports that...any recommendations/suggestions/configs?


I think so, and my evidence for that is I've been using tmux a lot less as I've done more of my development work locally.

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.


Or even terminal clients with split panes such as iterm. You can even configure it to autoconnect to remote servers on a per profile basis.

But if you want that remote session to persist, tmux (or screen) are still super useful.

Memory usage? 20 terminal emulators will consume half GB of memory.

I don't understand: what in your opinion is in most of that 500 megs or so of memory?

the executable file is read-only, so the OS loads only 1 copy of it into memory, which is shared by the 20 processes.


That's 500 megs is after accounting for that.

NB: tmate.io is a great tool for multiplayer tmux.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: