Getting started with Tmux | Hacker News Reader

Getting started with Tmux

linuxize.com

315 pointseaguyhn89 comments

Open articleView on HN

Some more resources for learning more about tmux:

- The Tao of tmux [0]

- A minimalist guide to tmux [1]

- Benefits of using tmux [2]

- tmux shortcuts & cheatsheet [3]

[0] https://leanpub.com/the-tao-of-tmux/read

[1] https://medium.com/actualize-network/a-minimalist-guide-to-t...

[2] https://blog.bugsnag.com/benefits-of-using-tmux/

[3] https://gist.github.com/MohamedAlaa/2961058

I really liked the Tao of TMUX.

I also made a very succinct cheatsheet for tmux (along with a list of all the other key CLI commands for full stack engs):

https://github.com/nemild/cli_for_full_stack#user-content-tm...

Tmux is another one of those tools whose siren call I'd avoided for a good decade, continuing to rely on GNU Screen. Then, for the last time I reconnected to a split screen and screen lost my splits and tabs - it was enough for me.

Two years ago I finally changed over and I haven't looked back. At this point, when I encounter something where I only have screen I'm rather annoyed by it - and I've set my tmux key mapping to basically mimic what I've been using screen for the last 20 years.

For me, tmux replaced every single feature that I used in screen. On the other hand, I'd be genuinely happy if it existed on the older OSes I randomly have to frequent, even if it's understandably impossible.

The one thing keeping me from switching is the lack of command classes[0]. I want to be able to chain bindings, so "^a s a" does "ssh server-a", and "^a s b" does "ssh server-b".

People keep telling me that tmux is better (though I still don't understand why), but I lean heavily on chained bindings and haven't found a solution in tmux.

[0] http://aperiodic.net/screen/interface#command_classes

Totally fair, and I never missed it because I have a different approach. I always open the shell and execute my commands in it - regardless of screen/tmux, a straight bash shell, or xterms(etc).

I have a crazy amount of automatic generating shell commands, so that I basically need bash --login to trigger anyways.

Is tmux actually more reliable in this respect or have you just been lucky so far? I had a screen session running for three years with no problems.

I have a tmux session that's been running for almost a year with no problems. I don't know how long it will run, but perfect performance for almost a year is good enough for me.

My session has 8 tabs, and one of the tabs (my primary) has 14 sub windows (frames?) showing all kinds of good busy information.

Fair question. My environments are different now, so I have no need to have a session last that long. My longest screen session, like yours was years. My current longest tmux session goes back to April 23 2018.

Admittedly, I'd hope to argue that if I keep sessions open that long I'm the problem.

My favourite little tmux trick is in ~/.tmux.conf:

`bind r attach-session -c "#{pane_current_path}"`

All the terminals I open start a new tmux session (left as an exercise to the reader). I change directory to whatever project I'm working on, hit `C-b r` and from then on all panes and and windows in that session will start in the correct directory. Saves me a lot of cd'ing.

I use the following for cd bookmarking:

https://raw.githubusercontent.com/jakobi/script-archive/mast...

http://cryptonector.com/2007/04/c-shell-pushdpopd-on-steroid...

Ohhh, thank you! One of my biggest annoyances so far was exactly this - every time I split off a new pane, I'd have to cd back to wherever I was working.

If you want the directory to come from your current pane instead of the current session, it's a little easier:

  bind '"' split-window -v -c "#{pane_current_path}"
  bind % split-window -h -c "#{pane_current_path}"

https://github.com/mfarrugi/.dots/blob/master/tmux/.tmux.con...

This can be done too in MacOS by configuring iTerm2 to open a new pane in the same directory and using tmux integration. Cool part is you don't have to learn the tmux commands, but you can use the iTerm2 commands to split panes, among other things.

Edit: Added MacOs

tmux was an absolutely game changer for me. At first I thought I was fine just being really comfortable with shortcuts and splitting commands with my favorite terminal emulators but tmux along with tmux plugins ecosystem[0] is really a world of difference, and much better.

I haven't gone so far as to change my default shell to tmux in the terminal emulator I use, for the sole reason that I imagine that I just don't need tmux every single time. In reality, 99% of the time the first thing I do when I restart my computer and open a terminal and run `tmux`, and start setting up my workspaces based on what I've been doing, naming windows, etc.

The top two features I use every day:

- keyboard-only selection + cut & paste between panes (yes, piping to xclip is good, but it's nice when you can just enter the right tmux mode, use emacs/vim keybindings to go up and copy out some text)

- easy/instant resizing and organizing of panes

- naming/breaking/moving/combining panes, to focus my efforts (something as simple as naming a window appropriately focuses my efforts inside that window)

An example of this is working with tools like `kubectl` that generate randomly named components that I have to list out @ the command line and do operations on, most of the time when I watch people deal with this in talks, they have to go and double-click-select or type things out.

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

Check out tmux-fingers by morantron. It lets you copy any line that matches a pre-defined regex. I just recently got a PR merged that supports kubernetes resources. So now I don’t even have to click the line (in mouse mode) and then hit shift+4 and yank, instead I just hit prefix+F and then the corresponding letters that appear.

Kinda hard to explain, but it’ll make sense if you look at the gh repo.

[It’s always driven my insane how kubernetes names its pods. They still haven’t implemented regex matching - there’s an issue on github related to that that went stale. For now I use a combjnation of selectors and old school unix regexes (awk, grep, etc) when I’m passing around kubectl commands that I need to work rgardless of whether the container has restarted or not]

Thanks for the tip! Usually since I've just run a `kubectl get pods` or whatever I use the keyboard navigation to go up a few lines, ctrl+a and use the emacs bindings to yank...

I just downloaded and installed tmux-fingers with tpm, but it's doing a pretty terrible job of picking up on the right things... I'm assuming i need to put in the predefined regexes that would match pod names/ lines of the get output?

It works for the output of kubectl get all, not kubectl get po unfortunately. [This is because without the resource name as a prefix, there’s no general regexes that will work for everyone’s situation] As a hack I sometimes end up doing kubectl get all | grep ‘pod/‘, which is a little inelegant. You can add your own regexes (see the readme of tmux-fingers, you do @fingers-pattern-0 your_regex) and then reload the config

Realistically I suppose it’s only marginally faster than kubectl get po -o name and then manually copying.

For any project I work on frequently I set up aliases that wrap it anyway. As you already know kubectl doesn’t allow regex matching so I just do something like: kubectl delete pod “$(kubectl get po -l app=MY_APP_SELECTOR)”, etc. naturally your deploy needs granular selectors otherwise you need to further pipe to grep or awk

> first thing I do .... and start setting up my workspaces based on what I've been doing

There are plugins for that! tmux-resurrec will restore your sessions on reboot, including directories and env vars. It can use vim and emacs sessions to restore your editors too. And you can also tell it other custom "safe" commands it is allowed to restore, which I use for stuff like repls.

oh yeah, I know! I tried using it but it was pretty buggy last time I tried (this was ~1/2 years ago), so I stopped using it.

I'm sure it's better now, but I don't keep that much stuff around so I don't think I'm too inefficient in not using it

It's definitely a tool that, once you get used to using it, it is hard to imagine not using it.

I find both tmux and Gnu Screen difficult to config (haven't taken the time to learn) but I love the concept of them so I use Byobu (http://byobu.co/) on top of tmux/screen to set common configuration for you. Byobu really lowers the amount of config and barrier to entry because Byobu uses common hotkeys. For example F2 for new window.

Thumbs up for Byobu - a great wrapper that makes using screen or tmux less clunky for me. The default config & hotkeys are intuitive, never had the need to alter them.

I never saw the need to configure tmux.

I have tried to configure bash for better use it (including launching it automatically) but then gave up due to not enough gain. But I never saw a need to configure tmux itself.

I can't say the same about screen. At a minimum, there's an inherent incompatibility between it and emacs.

Here's my entire .screenrc:

--------------------------------------------------------------------------------

## Control-^ (usually Control-Shift-6) is traditionally the only key chord not used by emacs

escape ^^^^

## disable all the 1970s era "flow control" operations so I can actually use emacs

defflow off

--------------------------------------------------------------------------------

The first line sets the prefix key to C-M-6 which is not used by emacs. The second turns off the "ctl-f" flow control stuff so emacs gets that chord. I then use emacs itself for all "window" management and terminal multiplexing.

It seems to me that people tend towards wanting to configure programs like these before they really grok them. Vim is another: I don't think it needs 100 plugins to fulfil its purpose.

Emacs works perfectly well for me inside screen, but not inside tmux. In tmux, many of the extended keys aren't quite right.

I run urxvt.

I also have custom fixes for rxvt that I've built up over the years, both a custom terminfo file, and fixes for emacs' terminal mapping.

I'm willing to bet your "inherent incompatibility" is a terminfo or similar terminal code interpretation problem.

I also run screen emacs and urxvt. For what it's worth I choose screen over tmux mostly because I've worked fairly hard at keeping most of my stack gpl.

Sounds a bit like a children of screen and midnight commander ;-)

I must admit I'm a screen guy. I feel not at home when I find a system without screen and I miss the "killer feature" of connecting to any tty at any baud rate

  screen /dev/ttyUSB0 9600

in tmux. But recently I tried to switch to tmux and found a few useful configurations.

1) I have alacritty as a terminal so no scrollback and no tabs (yeah there is a scrollback branch, but why duplicate functionality?) So my default setup right now is that alacritty (I use i3 so alacritty is bound to meta+enter) opens with this line (this way only one terminal can be opened and has always the same state)

  tmux attach -d -t alacritty || tmux new -s alacritty

So I got scrollback and tabs. Also I added

  bind-key -n C-t new-window
  bind-key -n C-PPage previous-window
  bind-key -n C-NPage next-window

to the config so I can use it like any normal terminal with ctrl+t (new tab) and ctrl + pgup/down to switch between them. In theory I could even add shift with (C-S-t), but this somehow doesn't work for me and I found conflicting information on it and some outdated infos so I just stopped looking.

The second configuration that I like to use is what everybody uses

  unbind C-b
  set-option -g prefix C-a
  bind-key C-a send-prefix

to change the prefix to the sane ctrl+a screen default.

Also setting colors is a must for neomutt and co

  set -g default-terminal "tmux-256color"

I'm still experimenting with configs for my desktops and servers, but I'm feeling a bit more at home with tmux right now.

Oh and for anyone who doesn't know of byobu check it out http://byobu.co/ it's a wrapper around screen and/or tmux and is easy for beginners and a nice change for everybody else.

I assume people change it from ^B so it still works in vim and less - that's why I changed it - so I find the popular ^A prefix particularly baffling, given how useful it is with programs that use readline i.e. every shell.

I do the same thing to auto open tmux and block any new windows from being created. If there is one, it instead opens a new tab when I run my hotkey (ctrl+alt+t). I have shift+arrows to switch between panes, and ctrl+a C to create them.

Just out of curiosity why is ctrl+a more sane than ctrl+b?

Like I said I'm a screen guy so I'm used to ctrl+a and I got my keymap remapped so that caps lock is ctrl so ctrl and a are right next to each other b is in the middle of the keyboard and I find it irritating having to press ctrl and b.

Also I don't use ctrl+a but the home key so I'm missing nothing.

One feature that I really like on my Mac was iTerm2's persistence (tabs and outputs preserved across reboots). This is particularly important where I live because we have frequent electric outages.

I now have something on Tmux with https://github.com/tmux-plugins/tmux-continuum .

That's one of the best things about Tmux: there's generally a way to get it to do what you need it to do. Or something close enough.

Cool I didn’t know ITerm2 was persistent across reboots. I like it because it supports inline matplotlib plots both locally and remote SSH connections.

One issue I have with tmux is that you can't resize the window to the current device. The developers seems to be very adament that it isn't implemented.

Currently tmux will adapt the size to the smallest (on each axis) client. This doesn't work well with persistent connections from a phone and PC since they typically have quite different window sizes.

In screen I hit ctrl-a + F to resize to current client and I miss it every time I use tmux.

Unfortunately I still prefer tmux, worth trying out if you haven't!

Maybe I'm not understanding, but if you attach to a tmux session with the -d flag, it will detach the session from any other clients and resize it to the window you're using.

Yes, and maybe that is the reasonable thing to do, but I don't want to detach.

When an application queries the screen size from ncurses or some other lib, what value do you expect it to get?

I don't think it's a reasonable requirement.

I'm very happy with screens implementation. It will stick to the size of the first client and you override it at will in any other client or if you want to update the size (maybe you changed the size of the window).

Oh, that's reasonable. Sorry.

I'm curious about your setup and why you wouldn't want to detach smaller screens.

I don't want to detach my desktop just because I want to check current status on my phone. Maybe I have two sessions on two computers and I, temporarily for a few commands, want to go fullscreen. With tmux I have to detach the other client(s), go fullscreen, and when done I have to reattach the client(s). This for something that takes a command to adapt and again recover in screen.

It is just an inconvenience, nothing huge, but big enough to obstruct my flow.

Curious. What do you do with tmux on phone?

Anything I do on my desktop that the mobile keyboard allows for (conveniently), I attach to the same sessions. But the most common one is IRC. And for that I still use screen just because of this issue (I always have IRC attached on several clients).

This still hasn't been fixed? I checked out tmux 7 or 8 years ago and this was the pain point that tipped the scale from "it's just as good as Screen and it doesn't have all the hardware terminal emulation code I will never use" to "it breaks a workflow for me, I'll check it out later".

What should happen for the smaller client then? Just show a cropped part?

Yes, anchored to the left-bottom. Still very usable for light work in many cases and you can follow along. And if it isn't a quick ctrl-a + F and you are all set.

This also prevents one session over multiple displays with different orientations/resolutions.

I use a macOS laptop with iTerm2 to connect to a remote tmux server running on Linux, and the iTerm2-tmux integration [0] is pretty great if you like multiple panes per window. I don’t have to mess with mouse mode for straightforward pane resizing, buffer scrolling, or copy/paste text in the buffer. I recommend taking a look if you’re typing on a Mac.

[0]: https://www.iterm2.com/documentation-tmux-integration.html

I never learned the "real" tmux and always using `tmux -CC` and `tmux -CC attach` on a iterm. Anything else you do differently in your workflow?

Use it with autossh for automatically reconnecting during computer standby / internet drops. I used to use Mosh + TMux for super durable connections and that worked beautifully. Unfortunately Mosh doesn't play well with ITerm's native integration so you can achieve a poor man's Mosh by using http://www.harding.motd.ca/autossh/.

All-together it looks something like this: Open iTerm. autossh -t myRemoteHost "tmux -CC -A"

I'm using tmux myself for persistent shells on remote machines (mostly irc), but not much otherwise. Lots of people and guides make it sound like it's also very useful when you're working locally. Can someone enlighten me what tmux can do for you in this case that people are so excited about it?

I used it locally on a project where I really needed 5-7 shells opened in specific folders and some of them running specific things. Tmux made it easy.

Scripted sessions are pretty neat and having a consistent cross-platform interface is nice. But it depends on how much time you spend in the shell and how much you're willing to deal with OS native keyboard shortcuts. I've also been known to abuse tmux during demos, keeping pinned info in a small pane and working in others.

For me: Panes. It's all about the panes.

My tmux conf: https://github.com/EverettBerry/dotfiles/blob/master/ubuntu/...

I especially like prefix + & to kill the whole window, prefix + , to rename window, and prefix + ":break-pane" to split the current pane into a new window.

I like to be able to attach to my customary sessions quickly, or reinstantiate them quickly in case of reboot etc.

I use something like the following in my .bashrc:

  alias f='tmux attach -dt f || tmux new-session -s f'

That way I can recreate or attach to my usual session(s) without even taking my hands off home row.

To those who use a tiling window manager: how do you incorporate tmux in your workflow? Since I've mainly used tmux to show multiple terminal sessions at once, I found it to be redundant in a tiling wm environment. But I'm sure I'm missing out on other features that my wm cannot provide.

I use a tiling WM and I use screen solely for the detaching functionality. It means I can restart X without restarting things like irssi.

I only use screen/tmux when connecting to a server to preserve compile sessions/outputs.

Is it possible to have tmux allow mouse scroll in your active window? I always have to press CTRL+B to enable it which is such a pain. This is the only thing that slows me down when using tmux.

> set -g mouse on

I think in older versions it was called mouse-mode,

I probably know about 5% of tmux, but I freaking love it. I've had a tmux session with 12 sub-windows running on a server for 300 days. I connect to it daily, from different machines. It works. It does everything.

I have no desktop application that performs at this level. So my hat's off to the tmux developers. Like many other great open source tools, it's a critical part of my toolset.

I do things like:

  - nest tmuxes (up to three levels, with different prefix keys for each level)
  - one tmux session per workspace (git clone, whatever)
  - cscope on window zero of any workspace session
  - use a CSCOPE_EDITOR that starts $EDITOR in a new, appropriately named tmux window in the same session, and returns control to cscope
  - script the setup of my main session

My biggest complain about tmux is a change they made a few months ago, where they decided to show all the windows by default instead of only showing those in the current session. Even if you filter the sessions to show only those in the current session, it's still not the same way it used to be. For that reason, I have stuck with an older version. \rant

> You can detach from the Tmux session and return to your normal shell by typing:

> Ctrl+a d

Looks like someone uses 'Ctrl+a' as his personal prefix and forgot to replace it in that part of the blog post ;-)

Background: I use 'Ctrl+a' myself (and hate it that tmux uses Ctrl+b by default).

The trouble is that I use both the Ctrl-a (increment number under cursor) and Ctrl-b (scroll up) shortcuts in Vim pretty frequently. It gets annoying to remember to have to double-press that shortcut if and only if I happen to be using Vim inside Tmux.

Yep. Ctrl-a has been move-cursor-to-beginning-of-line forever. It was too bad that screen selected it at the beginning.

I rebound prefix to control-\ for this reason.

Yeah, it's two handed but seems to have a nice rhythm to it for me (caps lock is control).

Might want to try Crtl-space

I set mine to Ctrl-Space, but the most frequently used commands are bound to alt+something so I can keep some consistency between tmux on windows at work and i3 at home. The gneral theme of bindings is Ctrl for apps, Alt for the WM, Windows key for the OS, this works well even when the WM and the OS are the same.

In tmux, is there a way to make the logical screen larger than the physical screen - so you can (1) scroll around to see the whole screen, and (2) view different parts of the logical screen in different terminals?

Useful for mobile devices with small screens.

Might as well take the chance to ask here:

Is there a way to get the count of total tmux sessions being run on any machine, for all users?

I can do "tmux ls" but that only returns for the current user.

Wow conveniently enough I've been trying to get started on a Tmux & Vim environment and I've been running into walls on Tmux related guides.

That was a really good write up on tmux. I have used tmux for years but use it simply, every few months looking up something on DuckDuckGo as needed.

I only started using tmux like half a year ago, and now it is the first thing I start when opening my terminal.

Really improves development with cli tools.

My favorite feature is the mouse support, which makes the window names in the status bar clickable, even while logged on remotely.

What's everyone's preferred tmux prefix key?

I use Ctrl-J. So many C-* keys interfere with Emacs / readline.

Backtick! I came up with it on my own, but a few months ago I did some analysis of tmux.conf files on github (via the GCP public db) and it turns out that it's the 3rd most common prefix (after Ctrl+A and Ctrl+Space).

C-o for me, for exactly the same reason

I have a nested setup with a "meta" screen session with escape key ^Z, which holds named "project" screen sessions with escape key ^O.

I background tasks in the shell seldom enough (because I'm always in screen) that I don't regret ^Z being slightly less convenient. ^O is a fairly unknown but very useful insert-mode binding in vim, but I use emacs these days so I don't notice it being escaped.

Before I used separate escape keys, it was maddening trying to remember how many times to hit ^A to send commands to which nested session.

C-o is moderately useful in emacs to move your current line down while the cursor stays on the newly created line.

C-Space so my thumbs (and ears) feel important.

Ctrl+A but I also remap caps lock to control.

c-x for me. with control on caps, it feels quite comfortable.

Minor mistake, for detach, it's ctrl-b d by default, not ctrl-a d which is screen's shortcut.

I've been using tmux and vim since 2012 and haven't looked back. it's wonderful!

«tmux a -t 0» > «tmux attach-session -t 0»

Reply on news.ycombinator.com