Tmux Tutorial | Hacker News Reader

Tmux Tutorial

leimao.github.io

459 pointskeyboardman164 comments

One tip I didn't see mentioned (though it's pretty common in tmux) is to use the default window layouts for organizing multiple panes. You do this with Ctrl + b followed by esc + <num>.

esc + 1: All windows take up equal space horizontally, and stretch the full vertical width

esc + 2: All windows take up equal space vertically, and stretch the full vertical width

esc + 3: The first window takes up half of the screen vertically, and all remaining windows divide up the space equally

esc + 4: The first window takes up half of the screen horizontally, and all remaining windows divide up the space equally

esc + 5: Windows are divided into two equal columns horizontally, and split remaining space vertically.

Even if I have to alter the sizes a bit usually, the pre-defined layouts are super useful for positioning different windows.

Just to nitpick a tiny bit, but you mean "panes" and not "windows". Tmux's terms can be slightly confusing and the difference is important in usage!

Good point, thanks for that. Fixing now!

Additionally you can cycle through these with <ctrl-b> + <space>

Or just jam ctrl + b + space until it looks good.

Thanks for this! :O

Man, many thanks!

instead of ESC you can also use ALT (maybe easier to hit for default keyboard layouts)

If you're on a Mac, try tmux -CC with iTerm2. You get tmux goodness like multiple panes, persistent sessions, etc. But you also get native scrolling, native copy and paste, etc. It's what makes tmux usable for me.

Amen to this. tmux is nifty by itself but the native experience is SO much better.

And with CC mode you'll not need all that complicated shortcuts. (I'm using tmux -CC for 1 year without knowing this shortcuts)

Is there anything similar or comparable available on Windows?

tmux -CC really is great on mac, but if it worked with mosh it would be incredible.

EternalTerminal works great as a mosh alternative and fully supports tmux -CC

Alternatively, there's apparently a forked version of mosh out there with iterm2 support hacked in, but I've not tried it.

The real purpose of mosh is to make remote sessions usable over extremely poor connections (i.e. high latency and loss). EternalTerminal doesn't make your session work nicely from an airplane like mosh does.

The featuresets of Tmux and mosh conflict directly.

Unfortunately.

Absolutely! TMux is pretty great by itself, but it doing its own internal scrolling and copy-pasting, though essential, is a usability frustration.

Tmux + iTerm2 is a fantastic combo that takes all of Tmux's pwer and removes all the downsides.

I searched if anything else used Tmux's Control Channel on Linux to replicate iTerm2's features, and I'm sad that I found nothing.

(Frankly, it's kind of stunning to me that one terminal app on macOS has more useful features than the plethora of me-too terminals on Linux)

> Frankly, it's kind of stunning to me that one terminal app on macOS has more useful features than the plethora of me-too terminals on Linux

If by "useful features" you mean intercepting tmux output and having it integrate with the terminal, then no. But more generally, I think the closest thing to iTerm2 on Linux is Tilix [1].

[1] https://gnunn1.github.io/tilix-web/

Well on a related matter I've been searching for years for a Linux implementation of the bog standard terminal window on my Macbook, that persists scrollback and history for all open tabs during reboots etc.

Such an enormously usable thing, why isn't that readily available on Linux?

Iterm2 is the number one Software driving my Mac productivity besides OS X itself.

So much of it is lost because work machines have been either windows or Ubuntu. I tried a few things but nothing comes even close to the level of overview and speed you have with iterm. In the end I usually end up using multiple windows and too much mouse..

The tmux integration is just the cherry on top

Yes! And it works on remote machines too! SSH somewhere and give it a try

The combo of mosh+tmux (and earlier, screen) really is something powerful that most non-command-line people can't ever begin to fathom. I've been mostly working through a terminal multiplexer for a couple of decades for work and pleasure and the benefits are enormous.

I of course use graphical applications for browsing, image editing, etc. but nearly everything else I do is from the command line and almost all of that happens over tmux, either locally or remotely. I prefer using a new Tmux window instead of a new graphical window for a temporary shell so I usually just end up having one terminal emulator running on my screen.

The value here is state: tmux keeps my state forever which gives me one less thing to worry about or remember. If I can't finish something right away, I know I'll just go back to the tmux window when I have time. Laptop running out of battery? No problems, I'll just reconnect when I find a charger and reboot my laptop.

For example, I have the exact cursor-to-cursor same view for what I do at work whether I'm at my desktop workstation in the office or using my laptop from the home couch. I can literally leave my cursor on a certain line, leave the office, go home, and continue exactly from where I was when I left, the same exact line. Especially using mosh makes it even more transparent: I just open my laptop at home and my work tmux session is already waiting there on my screen, and will update as soon as I reconnect the work vpn.

I'd much prefer to have something like this for browsing too. I'd like to run a browser muxer server that keeps all my tabs online with all the runtime state, making it available to me wherever I happen to connect from. Browsing something interesting on the train but then I had to hop off? No problem, I'd return to that session on the big screen as soon as I get home and open my laptop. Tab and bookmark syncing doesn't go far enough: I'd like to share one live browser process and access that from everywhere.

I could imagine I could rig up something like that using VNC and Xnest/Xephyr but a custom, hand-designed protocol for remote rendering natively in the browser might just work more seamlessly. I would like the browser in my phone to look like a mobile browser even if the content and state came from the browser server. And I definitely would not want to operate a desktop browser over VNC using my phone.

I have been using screen for almost 10 years now, is it worth switching? I know it's not much learning but why switching when screen is not broken? It feels like there's more important stuff I can learn.

I tried it for awhile, was puzzled by their choices of defaults, and ended up switching back to screen.

I prefer tmux to screen but the default key mappings took some getting used to. I've used it long enough that Ctrl-B and " / % for the screen splitting are natural to me now, but initially it was ... rough.

You could remapped whatever you don’t link.

I have Caps Lock set to be Ctrl and tmux set to use Ctrl+a. For a vertical split, I have it mapped to Ctrl+a, |. For horizontal, Ctrl+a, -

It’s pretty flexible.

Not sure why ctrl-a and ctrl-b are such popular prefixes, I use both a lot editing readline.

Exactly! Have you found any decent replacement?

I use Ctrl + q

Control-Space is perfect for me

And compliments vim really well if you set your leader key to space.

I use a backtick, but don't edit much e.g. markdown in my tmux sessions, and always use $(...) for command substitution so I don't normally feel any pain. One oddity with tmux is that to escape the control character you don't press it twice, you press the escape char then ctrl-b, so that is a lot of extra movement around the keyboard

Could you bind prefix + ` to insert a literal backtick? I've only ever used the default ctrl-b prefix so I'm not sure.

Backtick is my favorite too. Interestingly I thought it was an obscure choice, but it seems to be the 3rd most popular prefix from an analysis of tmux.conf files on github (after Ctrl+A and Ctrl+Space). I use `` (double-backtick) to escape the backtick and it's eminently reasonable.

I like ^Z, since it's about the only keybinding that's not used by common terminal software. To actually send a program to sleep, just double up: ^Z^Z

    # In ~/.tmux.conf Change prefix key to Ctrl+z
    unbind C-b
    set -g prefix C-z

I definitely hear you on ctrl-a. No idea what ctrl-b does, though?

It moves the cursor back one character (which is the default readline binding). In screen's case, you can send ctrl-a to readline by pressing ctrl-a a.

Forgive me for asking a sort-off-offtopic question, but what's the reason terminals - and therefore the programs which run within them - offer such limited scope for ctrl-key usage. A lot of characters are not available for remapping, such as ctrl-numeric-digit, or ctrl-shift-anything etc. What's the root cause of this? Is it telnet related? ssh? And, assuming there's a compromise somewhere, would it be possible for the problem to be lifted with a config option which says "I'm using this shell locally on my chromebook - please don't inflict this 40 year old restriction on me"?

> What's the root cause of this?

It is stems 100% from the terminal emulator. Just install a better one. Test your keys with https://metacpan.org/source/PEVANS/Tickit-0.67/examples/demo...

Screenshot: https://i.imgur.com/JfHjJXy.png

The only key combos marked not ok are global/taken by the window manager, so they don't arrive at the application.

Does screen offer splits? Those are game changing for me. I can't go back to screen without then.

Yes, vertical and horizontal

Tried tmux, then went back to screen. Tmux is for hipsters.

Totally agree. Also, screen is usually default installed on fresh distros. You have to go out of your way to install tmux

> You have to go out of your way to install tmux

You have to type: apt install tmux. Or, whatever your distro of choice's package manager install line is. I'd hardly call that going out of one's way.

Meaning what? It's different?

I feel like tmux is styled more towards Mac users, with rich UI and verbose options.

screen is more akin to a unix program that borrows the styling of options from getopts.

There is also the difference in licenses, and as in users voting with their feet, I chose the BSD licensed alternative to terminal muxing.

Comments like yours have nothing to do on HN

Another option would be to split screen's roles of "terminal multiplexer" and "terminal detacher" into two programs: dvtm and abduco, respectively. I find that approach more flexible than screen/tmux, and it works better spanning work environments where I might or might not have tabs and splits built in to my window manager or terminal emulator. It's also nice to not have to give up C-a or C-b keybindings when I don't need multiplexing (abduco uses just one key binding, and I think you could get away without it).

abduco: http://www.brain-dump.org/projects/abduco/

dvtm: http://www.brain-dump.org/projects/dvtm/

Better; use dvtm within Screen. This is what i do; one Screen session (fullscreen size) on my main dev box with each Screen window running its own dvtm instance. Thus each Screen window becomes a "workspace" (if needed, connected to a remote host) with dvtm-managed multiple tiles/shells. Flexible and not too complicated with all the power of Screen and the simplicity of dvtm. In fact, i use this setup even when working on my local machine. Throw in vim for the editor and you have a simple and standard setup which you can carry with you everywhere.

I appreciate the simplicity of abduco when saving sessions of already TUI-intensive programs like MUD or IRC clients.

When starting my GNU Screen journey 10-ish years ago, I immediately switched the meta key to Ctrl-K, which I had never used for anything in any app up to that point.

I often run screen sessions inside tmux if I need to ssh to remote machines. tmux is beautiful and I say that as a screen veteran.

> I often run screen sessions inside tmux if I need to ssh to remote machines

What possible reason can there be?

Maybe they mean tmux is not installed on the remote machine but screen is, so screen is inside the ssh session, inside the tmux session

Maybe for avoiding shortcut clashing.

I've had nested tmux sessions before. Usually I'll have a couple tabs on my local device, and then may want to ssh to a remote server and interact with a persistent tmux session there.

I usually make a point of setting different prefix keys in that case though.

I often run tmux in ssh in tmux. The outer tmux is just for my local terminals. The inner tmux is mostly so I can reattach later. Though it is also nice to easily get two shells on the remote machine side by side.

I switched from screen to tmux some years ago. Long enough that I can't remember exactly why. I held off for a while, but remember finding a handful of small cases where tmux was a bit smoother. Nuanced type things.

If you're using screen, you're already sipping the terminal multiplexer coolaid. I think it's the paradigm that's more important than the specific program/implementation.

I've been using screen for a while and came here to post the same question motivated by my thought that most likely we're probably not missing out on anything.

Working with multiples sessions is more convenient and ergonomic in tmux, don't know if screen caught up in this area.

> I have been using screen for almost 10 years now, is it worth switching?

I've been happy with the switch. I was a long-time `screen` user, too, and something that helped me a lot with the switch to tmux was adding a few lines to my ~/.tmux.conf to change the command prefix from ^b to ^a, like screen. It made the muscle-memory shortcuts I'd used for so long still basically work.

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

Hope that helps, and good luck!

I switched from screen to tmux two days ago (after a few failed switchover attempts in the past) and "bind-key a send-prefix" was the big thing I was most missing. Thanks for that one.

I've also mainly used screen for over a decade and it's good enough for one-off sessions, especially if your terminal supports tiling and panes by default, but I feel that tmux is more robust and easier to configure and you get tiling and panes out of the box that work in any terminal emulator. I think it's worth the switch, and I should set up a tmux again for myself too.

tmux adds more structure to windows, panes, layouts,.... which is not necessarily a good thing in the sense that you can't easily build an arbitrary layout from another arbitrary one. It all depends on your workflow, but tmux can't emulate the completely freestyle layouts of screen.

On the plus side, tmux has plugins that allow pretty sophisticated interactions (more than tmux)

not sure how screen is today but I switched to tmux because vsplits were builtin (back in the days you needed patches for screen)

screen has had a vsplit feature for several years now (ctrl-a |) in the screen package in the fedora upstream repositories.

I switched to tmux because of this bug: http://savannah.gnu.org/bugs/?26723 Huh, which apparently got fixed about three years ago, after being open for seven years.

After a years in the development doldrums, Amadeusz Sławiński took over as project maintainer of GNU Screen. Since 2014, he has done sterling work: fixing bugs and adding useful features with multiple releases between then and 2017.

I've been using screen for closer to 20 years, and switched a couple of months ago. Still undecided.

My major painpoint might seem minor, but: If you're using the default ctrl+a meta in screen, and usually keep ctrl pressed when cycling through screen windows, it will take some getting used to tmux as you need to release ctrl as it will otherwise read it as another combination.

Most other stuff is configurable to your liking, though I prefer adapting to new defaults to evaluate the mindset behind the tools.

It's otherwise less different than I imagined, and I'm not sure how much you'll gain from the switch. Unless tmux gurus know a lot of cool secrets that I don't.

I literally just switched in the past two months (actually, went from having used screen two jobs ago (~2 years ago) to using tmux at my current job). I'm on the tmux train now and I'm pretty happy with it.

If you've used screen for 10 years, learning tmux will take about 10 minutes. There's also some handy plugins: https://github.com/tmux-plugins

Really, if screen works for you, tmux isn't going to change your life. And I say this as someone who used screen for at least 10 years before switching to tmux.

I'm a long-time screen user, and I recently switched to tmux purely because it seems to handle high-color and unicode more cleanly than screen. I configured it to completely replicate my screen setup so that I didn't have to learn anything.

Do you mind posting your rc files for this config?

One thing I had in screen that I think tmux doesn't support is ..."stack keys"?

e.g., in screen I could configure "^a j p" to do one command and "^a j d" to for another:

> bind j command -c foo

> # CMD KEY NAME CMD

> bind -c foo p screen -t '% |db' make db

> bind -c foo d screen -t '% |prod' ssh prod

If that's possible, I'd love to know how. It's what stopped me from switching a few months ago, and is now the most painful change after switching again a couple days ago.

Ditto. I like the logging capabilities and multiple pane capabilities in tmux better than I do in screen.

Started with tmux, but during 4 years of using it updates broke my config files several times. Then around a year ago turned to screen and am really pleased about the decision: no more config-broking updates; available by default on most systems; by adjusting a few details was able to match my previous tmux setup exactly.

Oh man, I love tmux.

I guess I am not a very advanced user but some of its features really appeal to me.

We use Macbooks at work and initially I used iTerm2. I've always been a heavy user of the terminal and split views. (Neo)Vim is my main editor. However, I experienced difficulties switching back and forth between my work laptop and my personal Ubuntu system at home. I switched to tmux to be able to have the exact same set up on both OS's.

Although that was my initial reason for switching; I have come to love tmux. Just the fact that I can quickly SSH into my home machine, attach to my tmux instance and continue working from anywhere is amazing.

I tried to use tmux as a terminal multiplexer on sway just so I could make it remember a setup of terminals for specific projects. That way I could simply do `tmux-command start project-name` and have it automatically open a setup of windows and panes. Though I found it unfortunate that I had to learn new shortcuts that are different for shortcuts elsewhere. A simple example but which was a deal breaker was in order to work with its clipboard system, you had to use different commands. Does someone with more knowledge of tmux know whether it's possible to get rid of the prefix command somehow? I know about the i3 version of tmuxinator, but it doesn't support sway unfortunately. I might make something to automatically open a list of windows on a specific workspace for sway.

iterm2 (macOS only, alas) will make a local or remote tmux session work like a native tabbed iterm window.

Just use `bind-key -n` for a no-prefix bind

See e.g. https://unix.stackexchange.com/questions/450184/in-tmux-how-...

We use tmux for remote peer programming in a pinch.

If Alice has a session on a remote machine you have access to. You can run `tmux new-session -s bob -t Alice`

With this both share he same view but can move cursors independently.

> With this both share he same view but can move cursors independently.

Does this mean they have 2 separate cursors, or that that can control the same cursor? Your can sort of do the same thing in screen by using a nested screen session and sharing the outer session with the other user.

Even better than raw tmux is using tmate. I fumbled with tmux sessions and permissions for awhile but tmate makes it trivial. It's a free service but it really seems like they're leaving money on the table (I'd pay for it, anyway).

For those who customize their configs and, like me, SSH into all kinds of different short- and long-lived servers regularly: How do you stay sane?

I don't want to have to scp over my tmux conf to every single server I jump on, but OTOH difference in pretty much anything but the prefix gets really frustrating with habits. Particularly remembering all the emacs mode-keys when I really want the vi ones.

I customize/copy my configs on the boxes I use regularly and just learn enough of the defaults to get by on boxes I am using only occasionally (eg I know enough vi to get by but if I am using a box for a bit I install emacs and if I am using it a lot I copy my .emacs as well). It helps that I keep my configs small and in a single file for each program so I can copy them quickly if I need to.

For tmux, it will look at VISUAL/EDITOR so for vi keys you could just try to remember to run it as "VISUAL=vi tmux" or to run "tmux set -g mode-keys vi" if you forget.

Didn't consider that the mode can be set from environment variable, then it can just be automatically set from my ssh command, thanks for the tip!

Searching back in the buffer in emacs mode is the one thing I've been keep having to look up

I have a Github dotfiles repo so I can set it up on any server in a couple of minutes, just by cloning the repo and running a script within it. If you're jumping between different servers, I would highly recommend having a quick way to setup config like this. It's a short investment that pays dividends for many years - not just for tmux config, but setup for bash, vim, and any other utils you rely on.

I use one tmux prefix for the local machine and another one for ssh sessions (setup in bash_profile using something like `if [[ -n "$SSH_CLIENT" ]] ; then tmux set-prefix ... etc`. You need different prefixes when using tmux recursively like this, so you can navigate both the inner and outer session.

I also use a different color theme for ssh sessions, whch helps to know which prefix to use until it becomes somewhat subconscious.

Used to have that actually, it's just too much of a hassle in today's cloud environment (I can easily SSH into dozens of fresh instances over a day and there's no way I'm baking my personal config into an image). I was considering to revisit and streamline that, but I imagine the cognitive overhead of different remote hosts having different configs is worse than what I have now (local=my config, remote=vanilla).

I just bind a different prefix and moved the bar to the top locally (I use urxvt+tmux with Ctrl+arrow keys etc to navigate tmux tabs instead of a tabbed terminal client) to get around the nesting issue.

I use git and GNU stow. ssh in, clone the repo, stow tmux. Takes ~10 seconds on a new host. Also includes all the other dot files I use (bash, vim, etc).

Can't believe I missed stow, this goes straight to the bucket list!

if you use iterm2 on a Mac, and aren't colour-blind, then there's a somewhat cool thing you can do with zsh+ssh: based on the hostname, change the colour of the tab to represent something like dev/test/qa/uat/stage/prod/etc.

Here's roughly what I use: https://gist.github.com/anthonyclarka2/f2aae1e167c7899d7d263...

It could also be adapted to anything other than ssh. For instance kubectl, aws cli, virtualenvs, etc etc.

Let me know if this helps, and if you have any suggestions!

I used PM2[1] as process manager for Node.js, Python services in the cloud servers. It did its job well, apart from ensuring that process is always up, it provided monitoring capabilities(incl. emails), capturing logs from the stdout among other things.

Recently I wanted to manage a Golang service, found that PM2 is not stable for it yet and I didn't want to install Node.js just for managing the Golang service; so used Tmux for it. It keeps the process up, we can get the basic process stats as in any terminal and I use external monitoring service for alerts when the service is down[2].

[1]:http://pm2.keymetrics.io/

[2]:https://uptimerobot.com/

Tmux won't restart the service when it fails. It won't start the service when the machine reboots (or even if someone deliberately reboots the machine and forgets about the service).

Assuming you're on a modern Linux distribution, it's pretty easy creating a systemd service file which will make it easier to manage the service.

You're correct, I should have mentioned the purpose. I'm currently testing the service, want it stop when it fails and just not when I exit the SSH; hence the tmux.

For restarting the service, systemd is the way to go.

I use tmux in conjunction with tmuxp and highly recommend the pairing (or alternately use tmuxinator). a bash shortcut I use every day to attach/create/restore dozens of sessions is.

  pc:bt2$ cat ~/bin/t
  #!/bin/bash
  if [[ $# == 0 ]]; then
      echo tmux list-sessions
      echo
      tmux list-sessions
      echo
      echo tmuxp sessions
      echo
      ls ~/.tmuxp

  else
      tmuxp load $1 || tmux attach -t $1 || tmux new-session -s $1
  fi

usage "t session_name"

One of the downsides listed when you don't use tmux is that you have to type your password for each terminal you open to the remote machine. Does no one use ssh-agent?

This somewhat painfully breaks when reattaching as the socket from the shells environment could be defunct. Whereas the shell session outside has a different, totally fine agent in its environment. This was somewhat painful to explain to some engineers and I suck at explaining so I’ll gladly receive a good explanation for it (or a nice workaround?) :D

Are you talking about running ssh-agent on the server side? To further connect to some other machine?

For that I use a file to save the name of the socket and PID, and restore this in my .profile.

I assume it's referring to a password login, not an SSH key login.

I love tmux and use it extensively in my workflow. One thing that I found very useful was binding "synchronize panes" to ctrl+b+e combination, this allows me to quickly modify the configurations.

tmuxp is also a great tool for creating predefined layouts. Personally I store a config for every client and by typing "tmuxp load client_config" my session is immediatelly available and I can get productive within seconds.

Pro-Tip: Use it with autossh for automatically reconnecting during computer standby / internet drops. Use iTerm for a 'native' feel to tmux (ex. copy/paste, tabs, history, etc). 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"

Cool, a coworker showed me tmux yesterday.

One question we had was about scrolling in the tmux window and keeping the terminal output (as in Linux where I can scroll back with Shift+PageUp). Does anybody knows how that works with tmux?

You can enter scroll mode with ctrl+b+[ then you can mouse wheel, PageUp, etc.

To exit just press q or ctrl+c

ctrl+b, pageup is enough to start scroll back so you can skip [

Ctrl+B then page up/down. Mouse works too if you enable it in .tmux.conf

Note that you have to press Q to exit this mode :(

Looks like some of the shortcuts are really RSI prone, i.e. ctrl + b + & (where & is shift + 7). Are there any possibilities to have more wrist-friendly shortcuts?

Yes choose what you want.

Not sure if you know this, but you're not pressing 4 keys at once. The ctrl + b part is the prefix sequence to let tmux know you want to send it commands. The order of key presses would be:

1) press ctrl + b

2) release

3) press shift + 7

You may already know this, and the RSI concerns still stand (I'm not sure what all goes into RSI risks), but wanted to clarify if the concern is over pressing 4 keys at the same time that are all over the keyboard.

A very common change is to change the prefix to ctrl + a, like this in your tmux.conf:

  # remap prefix from 'C-b' to 'C-a
  unbind C-b
  set-option -g prefix C-a
  bind-key C-a send-prefix

I've heard that he reason for ctrl + b is because screen uses ctrl + a, which just doesn't make any sense to me. You can nest both tmux and screen and to get to an inner layer you press (if ctrl + a has been mapped) ctrl + a + a - and now your command is sent to the inner tmux/screen.

Defaults matter. It is not feasible to configure this on every machine you touch so one have to remember both the default one and the sane one...

There is no consensus on the best prefix so there is no point in changing it after 10 years. Lots of people dislike C-a.

I can imagine, what is best will likely depend on preference.

But at least the defaults should be sensible.

There is no agreement on what is sensible and what is not, the defaults are no more or less sensible than any other suggestion.

Oh, yes there are.

C-b is terrible for your wrist, especially in conjunction with the following commands.

Choosing C-a isn't as much about preference as it is about not-terrible ergonomics. Now people are right to prefer anything other than C-a or C-b but C-a is objectively a much saner default than C-b.

Absolute nonsense, are you trying to press C-b with one hand?

Yes. Left ctrl is in a better placement on many keyboards. Also being able to perform shortcuts with one hand is very handy.

If it hurts your wrist pressing it with one hand, perhaps you should use two...

Or choose a shortcut that works with either.

The problem is with ctrl positioning, there was a time when it was more commonly found on the home row [0]. Rebinding caps lock to control turns the motion from an awkward wrist snap to a slight spreading of your left hand fingers.

[0] http://xahlee.info/kbd/keyboard_ctrl_vs_capslock_position.ht...

Personally I've bound caps lock to ESC, but given the emacs style shortcuts it does make sense. Thanks.

> C-b is terrible for your wrist

I always use the modifier key on the opposite side of the keyboard to avoid that issue. So for ctrl-b , I press the ctrl key on the right side of the keyboard worth my right pinky and press the b key with my left index finger.

I think another reason is because some people use Ctrl+a in bash for jumping to the start of the line.

Thanks, that is a good point!

use a better keyboard :P

One of the biggest improvements in my tmux productivity came when I changed my prefix (default Ctrl + b) to backtick (i.e. to `) I am a heavy user of tmux and spend a lot of time switching panes, switching windows, entering visual mode, detatching etc. so this really feels faster.

    # change prefix to backtick
    unbind-key C-b
    set-option -g prefix `
    bind-key   ` send-prefix

I might be missing something but how do you input character ` as is (in vim inside tmux for example) if it's bound to prefix?

I think sending double prefix actually sends the prefix to active window.

Yes, which also enables using tmux in ssh/mosh in a tmux session.

Backtick is a bit far away, isn't it? I literally have to stretch my left ring finger to hit it, so doing this for each tmux key command does add up I suppose?

I've been using C-z for the prefix for ages. It's conveniently nearly under the default position where my fingers lay and it also masks the mostly useless suspend signal which I seemed to accidentally hit every now and then. (If I really want to suspend my program 'C-z z' will do just fine.)

Switching around using, for example, C-z C-n/C-p is pretty fast to key in. You can keep ctrl down for support and then it reduces down to typing 'zn' / 'zp'. YMMV.

Ah you're right, I forgot that the keyboard I use isn't common/standard. Backtick is right above Q for me.

OT:

How can I use my Mac's mouse to switch the active window in tmux? I have tried Googling this and the .conf setting everyone says to use doesn't work.

Depends on your version so check your docs and man pages, but this ought to work:

    set-option -g mouse on

Pro-tip: if you are using iTerm2, you can set this as your "Send text as start" and always be in a tmux session:

    tmux attach || tmux new -s main

I also recommend remapping ctrl-b to ctrl-space (set -g prefix C-Space). Easier to hit and as a bonus, ctrl-b will work as expected when connected to a remote tmux session.

If you ever use more than one session, I think you'll probably need to change that to `tmux attach -t main`

Paging mileac: the tmux cockpit (*) is down and my productivity is suffering

http://cockpit.27ae60.com/ https://news.ycombinator.com/item?id=15432986

Another useful source for learning Tmux that helped me a lot is the free videos from Upcase[1]

They even show how to use Tmux with Vim which is my favourite setup

[1] https://thoughtbot.com/upcase/tmux

Another alternative is emacs server.

I run both.

Emacs's terminal emulator is almost correct but last few times I tried to use it I had trouble with certain curses-based programs.

Also, disconnecting tmux UI (and even restarting X) does not affect the session, and you can reconnect. Unfortunately, I was not able to reproduce it with Emacs for some reason, though it should be possible.

I've actually started using vim with its :term feature as a terminal manager. So, I'll run screen (and tmux should work as well), and then run vim in a single window. Then I can run :term to open a terminal window within vim and then use use different terminal windows to do my work.

As far as I know, M-x shell doesn't allow for running multiple shell buffers in emacs, but :term in vim will allow you to do so.

What's a good way to handle ssh and tmux, if I'm already in a tmux session in my desktop?

I'm in a tmux session in my desktop. Then I ssh into a server from within tmux. I want to start tmux to be able multiplex and detach from some tasks. What do?

Use ctrl+b once to send commands to local Tmux server, twice to send commands to Tmux running on remote machine you SSH'ed in to. I think this can go on, in theory, but I did not test.

I remapped the prefix locally, and run vanilla tmux on remote boxes.

This one is a gem of a thing.

What about byobu built on top of tmux? Isn't it more straightforward?

I've not used byobu in about a decade, but it has crashed on me in the past. I've never had tmux crash.

The other thing I didn't care w/byobu was that it had a clock in the bottom row. Once a minute my terminal window would light up telling me that something on that tab had changed.

It's really easy to tell byobu what you want to have in the bottom row. Press F-9 and select "toggle notifications".

Perhaps they've changed that issue since it doesn't happen to me at all. The only thing I'm missing though is possibility to save panes config. Unfortunately it is against the idea of reboot wiping everything down from the session...

Author/maintainer of Byobu here... Tell me more about your "byobu crash". Can you point me to any bug reports in either bugs.launchpad.net/byobu or github.com/dustinkirkland/byobu ? Thanks! @DustinKirkland

Hi Dustin, thanks for the response. Unfortunately this was nearly a decade ago on Ubuntu server 10.04, and I'm sure that a lot has changed since then.

If I have the time, though, I'll fire up byobu and see if I can make it happen again. I tend to leave sessions open for many months and it wasn't something which happened on a regular basis, and I never experienced it with bare tmux.

This is an acceptable tutorial but it could use a bit of editing to make the English more idiomatic. Also, except for the bit on plugins, I don't think it adds to or simplifies the man page.

Does anyone have a good setup for debugging? There is voltron, but without tmux it won't work well, and I'd love to see a good layout that I could easily use.

What's the fastest way to scroll back through terminal history? Native scrolling doesn't appear to work and you have to annoyingly enter copy mode first?

With `set -g mouse on` in ~/.tmux.conf, scrolling via mouse/touchpad works, at least in my setup.

Never understood why tmux had to be different and use ctrl+b when ctrl+a is already standard and much, much better.

They didn't want to clash hotkeys with screen when tmux was first released.

isn't ctrl+a the BASH default for 'go to the beginning of the line'?

It is. If you're using screen, you can press ctrl-a a to send ctrl-a to readline to go to the beginning of the line. ctrl-b will actually move back a single character. Presumably, you could do something like ctrl-b b in tmux to move back one character, but I haven't tried it, so I don't know if that would work.

Am I the only one using screen? Couldn't switch to tmux since most of what i need is in screen.

Can we do vertical splits in screen without having to install additional plugins? How?

Yes. https://www.gnu.org/software/screen/manual/screen.html#Split

What features specifically are in screen that aren't in tmux?

I happiky use about 1% of Tmuz and and only truly understand half of that. Still super useful.

For someone using i3 WM does Tmux offer any benefits?

Yes, leaving a session running in the background/remotely though you might get disconnected or what ever. Same as screen.

Reply on news.ycombinator.com