An introduction to Tmux | Hacker News Reader

An introduction to Tmux

perltricks.com

125 pointsfrenky90 comments

Worth noting that you can enable mouse mode which is significantly easier for scrolling. It's also recommended by most people that you remap Caps-Lock to Ctrl and change the activation key from b to a. There are some great themes that make it nicer to look at as well.

I use tmux all the time for things like sshing into a vagrant box. As soon as I'm in I can switch between the tail of my logs, the readout of my build tool, the dev server readout etc. No more fumbling around starting multiple ssh sessions in multiple iTerm tabs. tmux honestly has been a game changer in terms of productivity just because of how easy it is to open things up and look at them. For those who are wondering why you wouldn't just use tabs in iTerm, its really more of an "also" not an "or"

I use emacs and most keys are bound. I'm really wondering what emacs devotees use with tmux.

Try this:

  unbind C-b
  set -g prefix `
  bind ` send-prefix

I use Emacs on and off, as well as Vim, and the key I've settled on for tmux prefix is ^q. It doesn't conflict with anything useful (that I've found anyway) and it's easy to hit with a caps lock as control.

For the record ^b is also move backwards by character in basic readline bindings (so it works in Emacs, on the command line, and everywhere on OS X). I've always found it baffling the programs like tmux and screen override readline bindings. Shouldn't those be on the list of bindings to never override?

In zsh (or at least with my configuration, which is prezto with a few plugins), Ctrl-q lets you "stash" your current command.

Say that you are typing some really long, complex command, and suddenly you realize that you are in the wrong folder. You press Ctrl-q (which clears the command and "stashes" it), then you cd to the right folder. As soon as you return to the prompt after issuing your cd command, your really long, complex command is back just as you typed it.

C-z for the tmux prefix key.

Suspend?

yes, at least for me, suspend is useless in both emacs and tmux, why waste a good keychord? :)

I use ^t because I never use the transpose-chars function.

Remap ctrl-b to ctrl-alt-b

unbind C-b

set -g prefix M-C-b

bind M-C-b send-prefix

Control-a is 'beginning of line'. Why would you possibly pick that?

A lot of people aren't used to the Emacs bindings. Home and End are still widely used.

Really annoys me when I have to work on a server that has the Ctrl-A bindings in tmux though.

Control-s/e/d/f/whatever you want then. The point is to avoid having to reach all the way over to 'b'.

It's what screen uses by default, and a lot of people come to tmux from screen so they already have the muscle-memory. Not sure of the original logic though.

You set prefix to C-a and then send double-presses on.

So C-a-a still does beginning of line.

Probably because that's how screen did it before tmux

> For those who are wondering why you wouldn't just use tabs in iTerm, its really more of an "also" not an "or"

In my case, I tend to ssh to one remote host, where I have a tmux session running with its own tabs, each of which is ssh'd to a bunch of other machines (10+).

By doing it this way, I can access all my remote ssh sessions from anywhere by just accessing that one initial machine and connecting to the tmux session.

I currently use tmuxinator to recreate the whole elaborate construction if I ever need to.

intersting use. I always wondered if that was managable because I'd be afraid to lose track of all those machines

I do the above as well with 1 addition, any of the virtual tabs on my remote host can also run a screen themselves. To control this I use Ctrl-Oo to control the outer screen and ctrl-a for inner screens. This is useful when you have a remote dev server for a particular app and want need multiple connections to it, such as running nodejs server and tailling the output in one shell while using the editor in the other. I only started using this recently but it has worked very well.

Here are some things that might be helpful for newcomers.

All those tmux commands, like set, bind-key etc might be put inside your tmux.conf file, as well as executed as commands directly.

For example, once you are inside a tmux session, simply execute them by prefixing with tmux:

  tmux set status off

  tmux set status on

  tmux set status-style "bg=red"

  tmux new-window

  tmux new-window -n "my window name"

  tmux rename-session mysession

Of course, you can execute them outside the tmux session too, you just need to tell it which tmux you want to control.

Open a new terminal, do not enter the tmux session, execute the following:

  tmux set -t mysession status-style "bg=yellow" 
  tmux new-window -t mysession

Inside a tmux session, tmux automatically knows which session you are talking about, so no need for "-t mysession" section.

Now, I hope you get the idea, you can manipulate tmux using a client-server architecture from the outside, this is the gist of the other tools like tmuxinator.

You could easily script tmux this way, so that it sets up 4 windows, one running your server, one running your db etc.

What the keybindings do is, effectively to map these commands to keyboard shortcuts, you can also execute any command using `C-b :`, similar to how emacs can do `M-:`. I think tmux was in some ways inspired by emacs.

Hit `C-b :', then run one of the commands, `new-window`, hit Enter.

When you are satisfied with these commands, move them your .tmux.conf file.

However, note that it will not sourced (read) until after you restart tmux or you source it yourself.

Either quit tmux or do

  tmux source ~/.tmux.conf

Of course, you can similarly group your project-level settings to their own configs, and source them or start tmux with those settings with tmux -f.

  tmux source myproject.conf (inside tmux session)

or tmux -f myproject.conf (outside tmux session)

I recommend Byobu. Byobu is an elegant enhancement of tmux or Gnu Screen.

For me Byobu is for far easier to use than Tmux.

That's a really nice introductory video they have on the website. The classical music is also a nice touch.

http://byobu.co

Can you elaborate why? I saw most of the video on their website; it looked pretty similar to tmux (with different shortcut keys). Does it have any extra features? Perhaps out-of-the-box session saving even after rebooting?

A couple of obvious reasons: 1) it lowers the bar of entry into Tmux/Screen for newbies; 2) it has fairly intuitive mappings for newbies; 3) it is sanely configurable whilst not requiring the direct use of a dot file (just hit F9); 4) it may be faster to set up than Tmux/Screen (assuming you aren't able to copy a conf file for those); 5) it doesn't require understanding Ctrl-b/a for prefixing most commands.

I watched the video for a while - and it looks almost identical to tmux - basically tmux with different key-mappings. I'd almost guess that the someone has simply gone and skinned the base tmux, everything looks so similar - panes, sessions, windows, resizing, scrollback, etc...

If you already are familiar with tmux, I don't think Byobu will get you anything (based on what I saw of the video).

Yeah, byobu is pretty much an opinionated tmux/screen (you can choose a backend).

As a long-time Screen user through PuTTY, I switched to byobu after watching the intro video and it is great.

It inherits and maps Ctrl-a, and makes the transition to using some of the nice new features available in tmux much more accessible.

Serious Question: Why would I want to use Tmux instead of iTerm with multiple tabs open? I don't think I get it. Can anyone ELI5?

Speaking as someone who doesn't use it, but understands it well, the one and only thing that excites me is the persistence of sessions, if your connection drops, you can reconnect and everything is still there. Love that idea. Everything else is solved that I know it does well (for me) by using tabs. I could very well be missing other things, I know it does quite a bit, but most of the things I see other people use it for is solved by tabs (for me at least).

This is the big thing for me. I used to work almost exclusively on a remote dev machine, using my laptop as a terminal, and tmux meant I could pick up in the morning where I left off the day before. Now, I work on a desktop, but I've gotten used to using tmux and using it locally means I can ssh to my work machine from home and, again, pick up where I left off.

Session sharing is also handy in specific cases. It supports both read only, and read/write shared sessions.

The other feature that's used often is the general scriptability that the command line options make possible. "send-keys" for example can be useful...it sends keystrokes to specific named sessions.

Doesn't mosh do that as well (or better)?

mosh only supports reattaching from the originally started client - no attaching from different machines, no resuming sessions after reboots, etc. Also no splits, and no scrollback.

It's also extremely slow. Fullscreen terminals on my 30" display are borderline unusable with mosh.

I kind of see what you mean, but tmux and mosh are completely different things and have (almost?) completely different use cases. Mosh is replacement for ssh.

Without talking about the other huge benefits of tmux, mosh only helps (and was designed to) prevent disconnections and other inconveniences when your internet connection falters. If for example your terminal unexpectedly closes you can't reconnect to your ongoing mosh session (this is an intended feature for security reasons).

Tmux on the other hand wouldn't help against a poor internet connection, but at least if your terminal or your ssh session closes you can just restart another one and wouldn't lose anything.

In other words, always use tmux, and tmux+mosh if your internet connection is poor.

In addition to persisted sessions across ssh, you can also split windows horizontally and vertically, rearranging them on the fly.

There is a nice function that I think GNU Screen does not have: C-b <space>. It rearranges all the windows dynamically, similar to dwm[0] layouts.

[0] http://dwm.suckless.org

I use tmux and screen mostly because of their "detach" function, so I can connect to the machine over SSH and attach to existing pseudo-terminal later.

It is significantly more powerful. With key bindings you control or scripts you write, you can move/split/combine your tabs/panes/windows in any way you can imagine, which for me is more ways than iTerm allows.

Ever SSH into the same machine twice? Put tmux on your servers. Or use it to leave jobs running and check on them later.

Edit: Almost forgot. If you use a console editor like Vim or Emacs (well, Emacs people probably do this all inside Emacs) you can basically build-your-own IDE by running arbitrary code in tmux panes (again, your imagination is the limit here) or send code to a REPL or...

Since you're using iTerm, here's a fancy little trick:

If you're connected to a remote machine, run 'tmux -CC'. Tmux tabs on the remote machine will appear as iTerm tabs on your local machine. (This works for attaching to existing tmux sessions as well: 'tmux -CC attach'.)

Interesting. The only thing I could find on the man page with CC change cursor color. How did you come upon this?

I don't believe it's actually a feature of tmux itself, but rather iTerm. My suspicion is that iTerm watches for that command in particular and rewrites it behind the scenes.

I was told about it by a coworker - more detailed info can be found here:

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

On your own machine, I don't think there is any reason (others may disagree!)

On another machine, your session remains alive even when you disconnect.

You can get the best of both worlds with iTerm, by running tmux -CC, which shows tmux's seperate tabs as iTerm tabs, which is super-cool when you are connected to a remote machine!

I much prefer tmux because it really doesn't matter what system I'm on, I can easily rearrange windows/panes and form a custom workspace. While iTerm can do this on the local mac, it's a real pain to use tabs/splits in it over SSH. Plus, like others mentioned, tmux stays alive.

I also just prefer the interface of tmux. You can completely configure your status bar as well, and I find that really useful. For example, my status bar [1] has my current music, host, time in the two timezones I care about, and load. I also use a commandline chat client for work that I can embed into a tmux pane and never have to switch away from iTerm to communicate.

[1] http://i.imgur.com/XrKtV7J.png

I love tmux but it appears to be messing with my terminal colors for some reason, especially in vim and after enabling 256 color mode.(Also the line numbers in vim appears to be bold in tmux when they aren't if run directly from the terminal, weird.)

A couple of potential fixes:

  # Force tmux to assume the terminal supports 256 colors
  tmux -2 

  # if /usr/share/terminfo/x/xterm-256color exists
  export TERM='xterm-256color'
  # otherwise
  export TERM='xterm-color'

Tmux recently merged a PR adding 24-bit colour, I'm a lot happier with the colours now. I think it will be in the next release if it's not out already.

https://github.com/tmux/tmux/pull/112

You may have hit the difference between what a terminal is capable of, versus what it's actually capable of. Most modern terminals can do all kinds of fancy things like mouse-support and 256-colour output, but they advertise themselves as 1990s-era 8-colour devices for compatibility reasons. Specifically, they set $TERM to "xterm" or similar.

tmux is two kinds of terminal application: it interacts with your outer, "real" terminal, and it presents an inner, "fake" terminal to the programs running inside it. By default, tmux will respect the limitations implied by $TERM, so if your outer terminal claims to be an 8-colour device, tmux will filter the colours of applications inside it to fit the standard 8-colour palette.

Vim also respects the limitations implied by $TERM, but some people override it into using 256-colour mode anyway, by doing something like "set t_Co=256" in their .vimrc. That works for Vim running in the outer terminal, but it doesn't work for any other tools running in the outer terminal, and in particular it doesn't help tmux.

These days, it's generally best to configure your terminal app to set $TERM to something like "xterm-256color", "nsterm-256color" (for Terminal.app), "putty-256color" (for PuTTY), "gnome-256color" (for libvte-based emulators) or similar. If your terminal application doesn't support manually overriding $TERM, you can do it in your shell profile. That way, every app should understand your terminal's capabilities, including 256-colour support, both inside and outside of tmux.

Discovering tmux and finding a workflow with it that works for me made me so much more productive

I have a really weird setup though.

I run screen on my laptop with a window for each machine I'm connected to. An irc box, a VM, a remote dev box, and a local screen. All of these Screen Windows I have a tmux session in.

I have a minima tmux config that makes resizing panes easy and fast to whatever size I want and whatever order I want.

It sounds stupid but I see people using multiple iterm or terminal Windows and I don't know how they do it. It just feels so slow to me. Tmux and screen are awesome you just need to find one that works for you.

You can also have nested tmux sessions instead of screen+tmux setting:

https://mutelight.org/practical-tmux

" Command Sequence for Nested Tmux Sessions

Often I'll run a multiplexer inside another multiplexer and need a command sequence to send things to the inner session. In Screen, this could be accomplished using C-a a <command>. This doesn't work out of the box in tmux, but can be fixed with a little configuration.

bind-key a send-prefix "

I can but I didn't like it as much. Screen out of the box with no screenrc was exactly what I wanted. now it's kind of stuck, as silly as using screen and tmux is.

Why do you use screen locally instead of tmux?

I use screen only to switch between servers. one of my screen Windows is a local tmux session.

It's wonky

One of the best tips I got when setting up tmux was to change the default prefix to ctrl+a. That combined with remapping caps-lock to ctrl makes working with tmux much more comfortable.

Or ctrl+s - (I use Ctrl-a all the time to go to beginning of line). Particularly if you remap Caps-Lock to Ctrl, it's pretty comfortable combination.

I recently stumbled across tmux while trying to provide a more customized UX in a bash script. Tmux and screen seemed a little more powerful than I needed, with lots of ways to accidentally corrupt the terminal. More and less were pretty close to what I wanted, but I could not figure out how to accept arbitrary input from the less prompt, exit, and pass it to bash.

Maybe that's not what less is for. Any tips on how I can create a less UX with custom input handling would be appreciated.

The select builtin might help in your case:

http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_09_06.htm...

Check out rlwrap.[1]

[1] - http://utopia.knoware.nl/~hlub/uck/rlwrap/

For future reference, if you want to replicate a git-like man page UX (using less as the pager) the trick is defining custom commands with lesskey[0]. You can specify the exit status of the "quit" action to pass the information back to the calling script.

[0] https://www.freebsd.org/cgi/man.cgi?query=lesskey&sektion=1

Is there a good explanation as to why tmux forces all viewers to view the exact same content? I very frequently want to see different windows (or whatever the terminology is) on different connections. Screen for example allowed that by default.

(I do know that you can do some complicated scheme of multiple-layers of indirection, but really why can't this just work by default?)

He missed one of the most useful commands - ctrl-b z - to zoom a pane to the full size of the window. Very handy for multi-line copy operations so you don't get other pane's content or border characters.

tmux is also a great way to keep your workspace available from other machines. eg. run tmux and all your text mode clients on a server somewhere and ssh into it.

nice! To think I have been using ^-b :break-pane the entire time…

I use tmuxinator to manage all of my tmux sessions.

While, I could write tmux scripts for everything the yaml format does just about everything I need.

I treat a session as a project, for example mux dotfiles will open a tmux session, cd into the correct directory, and setup and panes I want when working with my config, just one. On a customer project I often have one window for vim, then another window for the server to run, psql, and any additional services I need.

I have also found, prefix-s to be very helpful to switch between projects very quickly.

Recently I've come across the tpm (Tmux Plugin Manager), available at [0].

Happy with it, even though I'm only using two plugins: tmux-sensible (better defaults) and a theme-pack [1].

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

[1] - https://github.com/jimeh/tmux-themepack

I can only recommend tools like tmuxinator [1]. They make it really easy to start your development environment. Especially when you deal with multiple services that need to be started along with certain tasks (mostly watch tasks like build and test in my case).

[1]: https://github.com/tmuxinator/tmuxinator

Also https://github.com/oxidane/tmuxomatic, whose ASCII layout format I find stupid easy to create custom windows and screens.

Wow, that's pretty cool. I tend to use windows a lot though. Within a window I usually have 3-4 panes that I manage using Ctrl-B space to switch layouts.

I would recommend using mosh+tmux, rather than ssh+tmux, especially if you're using a laptop to connect to your remote development machine.

Ideally yes, but unfortunately mosh doesn't get through most firewalls, as far as I can tell. A lot of networks filter everything except port 22.

I sometimes tried that (and used screen for some time), but it never clicked. AFAIK the only advantage to a scriptable tiling WM is the persistence thing, but I never had a use-case for that.

Tmux is awesome. been using it for a while but still need to learn more about it. Its great to have a progress running here and checking on it later while on another window

I use it over ssh. 1 ssh session, multiple terms/windows/etc. And persistence of sessions.

The images depict manuals for screen.

Is this better than putty manager?

It serves a different purpose: putty manager is for managing multiple SSH sessions within a single app, but with tmux running remotely, you only need one SSH session, and you can leave it running when you disconnect, which is extraordinarily useful.

Is tmux a MacOS thing? I don't understand why would I want to use it on my machine. I already have a terminal multiplexer - it's called gnome-terminal and it supports tabs and multiple windows. Why would I want to add a clunky middle man with weird key combinations that messes with scrollback and colors?

For many people it will be the persistence of sessions on remote machines. I never use it remotely though and still love it, mainly because it's so easy to switch between windows and panes without having to use a mouse.

I used to love screen when I worked on a remote machine (no tmux on that machine, unfortunately). But it seems people are using it locally. Is it purely a matter of habit? In gnome-terminal, I'm switching between tabs with Ctrl-PgUp and Ctrl-PgDown and between windows with Alt-Tab. What can be easier than that?

tmux can easily split windows vertically/horizontally. I'm not using gnome-terminal, so I don't know if it or your desktop environment makes splitting so quick.

I could also imagine using one window manager on remote systems and locally is just easier to remember.

Opening up panes on Tmux is pretty nice - Prefix-" or Prefix-% to get Horizontal or Vertical Panes. Copy/Paste Buffers are useful once you get the hang of them.

Also - once you master it - it doesn't really matter what system you are coming from - the interaction is the same. Windows, OS X, Linux, Heck - OpenBSD console - the interaction is the same.

I wouldn't be surprised if my Circa 1980 IBM 3101 Terminal is mostly supported by Tmux. (maybe a missing Meta Key, but that isn't used that much by Tmux)

Well, beyond having to leave your home row and stretch for the PgUp/Down keys, it's nice not having to think about whether you're working on a local or remote machine, whether you're on a Windows machine in putty, on 127.0.0.1 with gnome-terminal/urxvt/xterm -- or given a proper setup, even whether you're using tmux or screen.

Creating new windows is the same command, switching between them is. And as others have mentioned, detaching processes without thinking about it beforehand (like you'd have to do if you start them with nohup/dtach).

Granted, the Xzibit-ness of it all grinds my wasted CPU cycle gears sometimes. Strangely enough, I haven't seen a setup where e.g. the X11 frontend just connects to a remote detachment & management daemon over ssh, so only one program is emulating ancient terminal hardware...

Not sure if I get exactly what you are looking for, but abduco[0] (with or without dvtm[1]) might serve you better.

[0]: http://www.brain-dump.org/projects/abduco/

[1]: http://www.brain-dump.org/projects/dvtm/

You don't just get tabs (one full-screen/window terminal at a time). You can split it into multiple panes horizontally and vertically.

I think, for me, is that I'm also an emacs user. I never liked using the shell from emacs (I've seen people do it, it always felt clunky to me). So it's a similar configuration, but for more than just the things I use emacs for and running any tools/editors (I still use vim from time to time as well). When trying to understand some new (to me) program with a decent man/info page I can open up two panes side-by-side and review the documentation while playing around with the tool.

Another benefit, to me, is that I'm not always on the same OS (locally). So I use it a lot remotely, but it also means I'm not trying to use (on linux and OS X) two different terminal programs with different behaviors. Having a consistent environment (like I've also done with emacs, zsh, and to a lesser extent vim), makes switching between systems a breeze.

Attach/detach is the killer feature if you ever use more than one computer in your workflow, i.e., if you're a programmer of any kind.

Definitely not a MacOS thing (though it runs well on OS X). OS X also comes with a terminal multipler - Terminal.app/iTerm 2.0 - but lots of people who work at the command line all day seem to like the keyboard support for multiple windows/sessions/panes that they get through tmux. The session persistence/reconnection is pretty nice for remote hosts as well.

>> I don't understand why would I want to use it on my machine. I already have a terminal multiplexer

I always feel the same way. I've got terminal set to open connections to 6 servers when I open it. I've tried using it, makes perfect sense to me, it's lovely, but I guess it just solves a problem I don't have? It's one of those many things that makes me feel like some kind of failure for some reason. Like using nano as my primary editor. I can use the hell out of emacs and vi, but for the work I do (I'm a sysadmin), most of the time nano just works, no weird issues, and it's always there. I know everyone is going to and laugh and me now, but there it is. I find myself using nano most of the time, though I'll use emacs a few times a week on some projects. Something about that long reach to the esc key keeps me away from vi.

When tmux might be handy:

If you find yourself doing repetitive things in those 6 windows. Say they are production machines that are basically clones of one another. It's simple to make a key binding that will force all 6 windows to, for example, "tail -f /var/log/messages". Or start "top" on all of them.

If you kick off a long running task (say a big build) in one of those six windows, and you leave it running, but go home and watch it finish. (detach/reattach). It's easier than stdout/stderr redirection, nohup, etc. It also preserves things you did manually (setting environment variables before the build) such that restarting a build might be less complex.

You have a peer, not close by, that you want to show how to do something. It has both read only and read/write session sharing. Your peer can watch what you're doing, or you can watch them, and take over when needed.

Your counterargument is a straw-man. If you wanted to use tmux, you'd set your own keys and spend a few minutes googling to fix the scrollback and colors. Tmux offers functionality that goes above and beyond the multiplexing built into most emulators.

Longtime users of tmux (like myself) find it elegant and speedy; not clunky.

I am also a linux user, but I can use an emulator with a much smaller footprint than yours and enjoy greater flexibility and control than you do.

Edit: see more positive version of this comment on adjacent thread: https://news.ycombinator.com/item?id=11411853

I had a similar thought for a long time, but then after watching a coworker I was convinced to give it a try.

I multitask a lot with multiple terminal windows, and what tmux buys you is similar to a tiling window manager with multiple desktops.

I used to spend a lot of time trying to figure out where I put terminal windows, and resizing them to a more ideal size for whatever I was working on at the moment.

Tmux allows you to have multiple (named) windows, each with multiple panes, that you can quickly rearrange, 'zoom', add to, separate, etc.

I find I get the most bang for my buck by setting the 'escape' key to simply `, instead of ctrl-a or ctrl-b. That way, window switching is simply `3, `1. `z maximizes or restores a window.

The problem with colors you mention is almost surely solved by simply launching tmux with '-2' as an argument.

It originated within the FreeBSD community (though it's not part of the project).

As to why you'd want it? I use it on machines I use remotely so I can have persistent sessions. That's the point of the likes of tmux and screen.

Also, gnome-terminal isn't a terminal multiplexer: it's a terminal emulator that allows you to open multiple terminal sessions in separate tabs. You're not multiplexing a single terminal in that case, unlike screen and tmux. If you want a terminal emulator that's more comparable to tmux and screen, take a look at Terminator: http://gnometerminator.blogspot.ie/p/introduction.html

The tmux/iterm2 integration on Macs doesn't make a lot of sense to me. Some people might be better served by moving to a platform with a tiling window manager.

The value depends on how you use your computer(s). If you are mostly working locally then something like gnome-terminal is fine. If you only ssh out to machines to run a handful of commands at a time you don't need it.

I can rent nice virtual machines anywhere in the world with great network connectivity and a lot of flexibility. Just about any computer can be used as a client. A secure shell and web browser is all I need most days.

I can detach from a session and reattach from another machine or even share a session with another person. Changing networks or machines or laptops sleeping doesn't cause everything in my session to get torn down and me having to set it up again. So for me the convenience outweighs the disadvantages. I don't run tmux on machines I only visit to do a bit of maintenance and I don't run it locally. And I only use a subset of the features regularly. But if I am working all day on a remote machine it is very practical.

Reply on news.ycombinator.com