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.
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.
> 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].
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 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 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.
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).
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.
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 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
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 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 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.
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 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.
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"?
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.
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
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'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.
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.
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 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.
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.
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.
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.
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)
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.
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.
> 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 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 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.
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).
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.
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].
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
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
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"
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?
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?
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...
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.
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.
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.
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.
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.
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.
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'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.
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.
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...
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?
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.
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.