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