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 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.
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.
Readit News
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.
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)
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/
Such an enormously usable thing, why isn't that readily available on Linux?
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
Alternatively, there's apparently a forked version of mosh out there with iterm2 support hacked in, but I've not tried it.
Unfortunately.
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.
abduco: http://www.brain-dump.org/projects/abduco/
dvtm: http://www.brain-dump.org/projects/dvtm/
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.
Hope that helps, and good luck!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.
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.
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.
What possible reason can there be?
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.
On the plus side, tmux has plugins that allow pretty sophisticated interactions (more than 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.
See e.g. https://unix.stackexchange.com/questions/450184/in-tmux-how-...
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.
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.
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 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.
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.
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.
Searching back in the buffer in emacs mode is the one thing I've been keep having to look up
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!