I like tmux a lot, but like its predecessor "screen" I mostly use it for explicitly running long-lived jobs (i.e. for its detach feature), and for very special situations where I have elaborate tmux window configurations with dedicated stuff running in each window/pane.
Note that I have been using text-only terminals since the 1980s, but I've adapted my tty usage over time.
The problem that tmux (or screen) brings are first and foremost:
* Smooth/fast scrolling goes away. I can no longer give my trackpad a slight push to find myself tens or hundreds of lines in the scrollback history, and visually scan by slightly pushing my fingers back and forth. Instead I have to use the horrendous in-tmux scrollback using "Ctrl-b [".
* My terminal app's tabs and windows are not tmux's tabs and windows. I cannot freely arrange them in space, snap them off with the mouse, easily push them to another desktop, and so on. I have to start a multiple tmux clients and do awkward keyboard interactions with them for any of the same.
* tmux's terminal emulation and my terminal emulator's terminal emulation (heh) are not congruent. As a result, programs cannot make full use of my actual terminal's capabilities. For example selecting, copying, and pasting text sometimes behave weirdly, and there are other annoyances.
What I'd really like to have instead is terminal session management at a higher level, i.e. involving my actual graphical terminal app itself. Attaching to a running session would mean restoring the terminal app's windows and tabs, and the entire scrollback history within (potentially with some lazy loading).
tmux could likely be a major part of that, by providing the option of replacing its tty-facing frontend with a binary protocol that the graphical terminal app talks to, while keeping the backend (i.e. the part that provides the tty to anything running inside it) the same as it is today.
As it is, the downsides of using tmux all the time are too high.
Not sure what this is tweaking (I'll check) but this does not seem to affect the described behaviour.. PgUp/Down does nothing - with and without shift - and mousewheel still just scrolls thru shell comand history and I need to use Ctrl-B ] to get into session output history..
I have the same exact gripes with tmux/screen, and I have a similar workflow requirements as you do. I'm currently using Shpool (https://github.com/shell-pool/shpool), which checks all the checkboxes you mention.
That is a far, far cry from using kinetic scrolling. In fact, using a mouse wheel is a very far experience away from that. I basically cannot use "normal" mouses with scroll wheel anymore for that reason, I couldn't get anything done like that.
I think there are/used to be some mice with a ultra-low-fricton "freerunning" scroll wheel. I guess that could be a similar experience, but of course tmux would stand in the way of that as well.
And I'm very old school and had been using text-only terminal starting in the 1980s...
I have been wrestling with having to enter scroll mode for so long now. It's so infuriating. It works without configurations on iTerm, but does not work on a single other terminal emulator I've tried.
I just tried your config setting in Ghostty and still, when I use my mouse it scrolls through zsh history, not the screen
Disclaimer: I generally prefer doing everything by keyboard and never touching a mouse
When you enter tmux scroll back buffer with "Ctrl-b [" you can reverse search the entire output and navigate within the buffer with standard shortcuts (same as man pages). I also added this yank plugin to copy any highlighted output to my system clipboard. Makes searching and copying output super fast
As far as I know tmux already copies things straight to X11 clipboard by default (at least in version 3.5a) and no configuration aside from enabling mouse is necessary.
For me, customized Vim search is just miles ahead of everything else so I prefer that (not just for the search, but also to open files with gF, etc.).
I also have a couple binds in Vim to deal with tmux:
> What I'd really like to have instead is terminal session management at a higher level, i.e. involving my actual graphical terminal app itself. Attaching to a running session would mean restoring the terminal app's windows and tabs, and the entire scrollback history within (potentially with some lazy loading).
Do you mean something like Xpra, x2go, NX, VNC, or Parsec?
It's a choice. tmux uses the "alternate screen" capability, the same way editors like "vi" do, which (according to man tmux): "preserves the contents of the window when an interactive application starts and restores it on exit, so that any output visible before the application starts reappears unchanged after it exits."
To change that behavior, put the following in your tmux.conf:
set -g terminal-overrides '*:smcup@:rmcup@'
set -g status off
I have. It's not even closed to the kinetic scrolling experience of native Terminal.app. It simultaneously scrolls one whole line at a time (instead of using pixel granularity), and ignores the terminal app's scroll bar indicator, which effectively means that if I give my trackpad a slight push in either direction, I get what looks like random flickering instead of the very natural and intuitive scrolling with a subconscious idea of where I am in a long buffer that any native macOS app, including the terminal emulators, give me.
I’m with you, smooth scrolling and copying/selecting is what’s been keeping me from using tmux full time all of these years.
I just wish Terminal.app had vertical splits and true colors. It’s just embarrassing that Apple hasn’t touched it in such a long time. I’ve been looking for a better terminal emulator for years and tried pretty much all of them, but begrudgingly end up back at Terminal.app
I don’t love the scroll back on tmux.
I found I was often using it with emacs in one window and a shell in another. On the ocations where I needed huge scroll back I would use emacs in both and would M-X shell and have a whole output buffer with emacs’s almost endless scroll. Of course emacs shell isn’t great… but it’s searchable and savable.
The first one I use for circumstances where I want to investigate a lot of different things in a dedicated cluster, without the hassle of having $(kubectl --kubeconfig ...) or the risk of k() { kubectl --kubeconfig ... "$@"; } and losing track of what context I'm in[1]. Because, with iTerm2's integration command-n or command-t opens a new window or tab but with retaining the credential scoping. If I need to change scopes, I can just detach from the tmux session, attach to a different one, confident that I don't have any variables to unset
The second I use in "standard" setups where I want to view the same configuration every day (say: web, api, database pods). Having teamocil allows me to either have those same commands laid out in the same pattern as yesterday, or I've also had pretty good luck just generating the yaml files because their syntax is simple enough
Personally I find tmux’s default split keys to be a bit obtuse, personally I like to use hyphen and pipe for horizontal and vertical splits.
Likewise i enable vim keybindings, mouse mode, and if you use a Mac and iTerm selecting text will automatically drop it into your clipboard ready to paste.
I tend to make use of the following command - which will output the last 100000 lines of the current pane to a text file local to you; it’s useful for documenting screwups, maintenance work, and of course making notes on what you’ve done for future reference
> bind-key P command-prompt -p 'save history to filename:' -I '~/tmux.history' 'capture-pane -S -100000 ; save-buffer %1 ; delete-buffer'
Fun fact the main WSGI server for prod AWS console has been running out of a detached tmux process since 2018. We are just really careful not to press Ctrl-D
My only non-truvial tip about tmux is that the only thing that one needs to do is to look for help: Ctrl+B then '?', and then figure the rest out.
When I learnt tmux, I had to access multiple VMs which were de-facto ephemeral, which meant customization was not an option anyway. I kind of learnt to like the defaults as they are.
Thank you for this. I'm trying to get better at vi(m) and I'm looking for something similar that I can pull up while editing a document - I struggle to remember some basic keystrokes when I need them.
My favorite tmux command from the shell is: "tmux new -A -s me", which I have aliased to "tm". It creates a tmux session named "me", or attaches to a session named that if it already exists.
I tried to move to tmux, mostly because the Red hat servers at work don't have screen, but I found out I really really prefer screen. The whole server/session/window/pane thing is overly complicated and somehow still less capable than screen's session/pane/window.
It's a tiny bit more scriptable, but it's not like a real API either.
I know it's a week old post so doubt you'll see this, but if you ever try tmux again, try remapping the control command to a single key. And remap the horizontal and vertical splits.
For instance, I remapped the backtick key since I rarely use it.
' | means split vertical
' space means split horizontal
' h,k,j,l means go to the left down up right pane.
' z means zoom the frame to full size
If you are interested I can show you my tmux conf. I'm not a ricer, the config I use is very simple, I find it just removes friction and makes it much more usable. Plus I can still type a backtick by pressing it twice
You can't attach the same windows in multiple locations with different layouts.
With screen, I can have windows 0 and 1 in a vertical split on my laptop, and windows 0 and 3 in a horizontal split on my desktop.
With tmux, you attach to a session and it has the same layout everywhere. You can have attach different servers or different sessions but you can't even show different windows in the same session, let alone have different layouts. If my laptop shows window 1 containing 2 panes, my desktop can only show window 1, and it will contain 2 panes. Changing the layout or the active window will change it everywhere.
I love it. I have this whole system set up where each desktop gets its own session. So, any time I open a terminal on desktop 2, I get session 2. Then I can make all the windows I need (I very rarely split anything, but cool to be able to) and close the terminal when I’m done. When I open it again later, it’s all still there. I used to absolute overwhelm myself with terminal windows; now it’s all organized.
I find the 4-level object model of tmux too complicated (server/session/window/pane). Even your use case, which is non-standard and meant to showcase the potential of tmux, only uses windows in sessions and does not need the complexity of tmux's object model. In fact it is totally doable with screen (one "session" per desktop, which is similar to a tmux "server").
I simply deplore that the tmux developers obviously thought long and hard about this design only to come up with something needlessly complicated and in the end less capable than screen's model (since you can't have different clients with the same windows in different layouts).
You included no arguments. You only hinted that something is "somehow" more complex and less capable.
Analogies usually help people understand things. I don't see why you're offended and obstinate, but you can of course keep it up if you like. Have a nice day.
I see. What you meant to say is "how is it less capable?" and you just misspelled that as "hurr durr I like nothing but hotdogs". You also straight up ignored the part where I listed the 4-level design that I find complicated. But I'm the obstinate one! Thanks for explaining.
Would also like to mention (tab-rs)[0] which has a much more unconventional take on multiplexing.
It is sad that it has not been maintained in a while (written in rust) as I much prefer the low cognitive load approach it presents (just fuzzy find) as well as the workspace feature.
Would be interested in knowing if there is something similar and maintained.
P.S. Does anyone here know how to make GNU Screen start up by default on a terminal launch?
Can it do tiling -- or any other kind of -- windowing, though?
I've tried it, briefly, and my impression was that it's full-screen (or full-terminal-emulator-window) only. Which means it's not the same kind of thing at all.
There are various full-screen terminal multiplexors out there, but the point is this:
* modern screens are big and can show hundreds of rows and columns
* very long lines are really hard to read
* So, I want a tool to split up that big space into multiple smaller windows. I want to be able to keep eyes on several things at once, side by side.
IMHO <https://cfoust.github.io/cy/replay-mode.html#:~:text=make%20...> is trying to drive down the risk of an Evil Operator reading my files as if it's the 90s at school but my modern risk is that some npm dependency exfiltrates the .borg files, which are readable by me, to North Korea. I was hoping to find an encryption option but did not
> Configuration: cy uses a real programming language, Janet, for configuration.
Can anyone provide some information on the differences between tmux and screen? Are there significant features missing from one or the other? The more "objective" (or unbiased) the better. As an analogy, I know of some features available in neovim not available on vim; they are not important for me, so I continue to use vim. On the other hand, the vim features not available in vi made me switch.
I use screen, but whatever I have read till now on comparison seems to point more to personal preferences.
For me, it's because it's more common to use tmux and you can find from legacy configs to modern ones. So, for me, that I have not studied IT (and now I work as a programmer) it's essential to find basic configurations all over the place to have an anchor.
But, as always... Use whichever works for you. Don't think in the "best" or the "most efficient" which is just youtube propaganda. Use whichever works for you and makes you feel like home. If that's 98's microsoft word... then embrace it and be proud to have an opinion.
1. if I start something which will run for a long time and/or the connection is unstable, I start a screen session on the remote node and start the program in it
2. if I want to check something (i.e. tail -f foo.log) on several servers at the same time, I start tmux on my machine, create 2,3,...,N panes and in each pane I ssh to the 1-1 remote server and start tail -f foo.log there. So I'll see the logs at the same time on several servers, just like if I had 1-1 monitor for each remote server.
I use tmux specifically for your first example. I'm not a power user, but after trying screen and tmux, I didn't find anything missing in tmux (relative to screen) and I found it easier to do the things I was interested in. I also like having the ability to attach to an existing tmux session or start one if it doesn't already exist by using something like this: "tmux new -A -s me", which I have as an alias and "me" is just a name for the tmux session. I'm not sure if screen has this feature, but I found this single command lets me get going with a multi-window session without having to first check if I already have a session running.
there's truecolor support (which is now available in screen 5) and the other thing is clipboard support (not sure what it's called exactly) which basically allows you to directly copy text from screen (or say, neovim) even from remote sessions. Can't think of anything else personally (oh there's undercurl support if you care about that).
I find screen to be more stable than tmux but can't say I had any issues with tmux in the past couple of years (but it bothers me that tmux sessions share the initial environment the first session was launched from iirc). Right now it's the clipboard support that makes me use tmux over screen.
> but it bothers me that tmux sessions share the initial environment the first session was launched from.
It does do this, but I am curious what would be better? I heard this complaint before and It baffles me. let me explain.
environments are... sticky, a child process inherits it's parent processes environment. so the tmux server starts and inherits the environment from the shell that started it, then each pane inherits the environment from the tmux server. As far as I can tell you want each pane to inherit the environment from somewhere else but can't figure out why or how that would happen.
My best guess is that you want tmux-attach to stash the environment it was ran in so that tmux could then use that when making new panes. my second guess is that you want tmux to use the current pane as the parent process for a new pane. both of which sounds like it would be even harder to control the tmux environment.
Any changes to ~/.bashrc or even ~/.tmux.conf would not reflect in any newly created session unless you terminate all sessions and start afresh. In screen, every new session starts from the current host environment which is more convenient
Not sure what bash is doing but tested with ksh and it runs and picks up changes in both .profile(login shells) and .kshrc(all shells) so I don't think it is tmux that is interfering with that aspect.
In fact I was a bit surprised that .profile ran on every created pane, as naively I would not have thought that would be a login shell.
not sure about the rest, I did read the man page again, and wow there is a lot more configurabilty than I first thought, however I found nothing great, the best I could come up with is.
bind c 'source-file /home/xxx/.tmux.conf; new-window'
There are three tmux customisations that I love and use all day:
1. Set the prefix key to C-Space. Much easier to type then any letter, and (in my case) only collides with Emacs set-mark. Its easy to remember and just type C-Space C-Space in that case.
2. Set IC (insert key) as prefix2. If you have a full-size keyboard, you can now scroll up by pressing insert (on the block of 6) and pageup. Easy to type.
3. Using sessions for ssh hosts. Add ControlPersist and/or AddKeysToAgent to ~/.config/ssh and bind the following to some key. Pressing that key will prompt for a hostname, and create a new session named after that hostname. The default-command will make it such that Prefix c will open a new window which is already logged in on that host. Its not the same as running a remote tmux, as your windows/session will not persist on the remote host, but it avoids nested tmux. I use it all the time during a typical day...
tmux changed screen's C-a prefix to a more sensible C-b. C-a is pretty universally used as "jump to beginning of line", which for screen meant that you'd have to git "C-a a" instead all the time. Seriously annoying, and therefore lots of screen configs changed the prefix away from C-a for that reason.
Okay, but C-b is "go back one char" and that's also pretty common? I'd personally lean towards saying maybe either C-z or C-s are better? Because suspending a process is a lot less useful when you've got a full multiplexer, and C-s is just... I guess somebody uses it, but I don't think I've ever used it on purpose and it's kind of annoying to accidentally freeze your terminal (and again, tmux has an actual scrollback mode which seems like it covers that use).
Good point. Though C-s is fine unless you have software scroll control enabled, and it's used in emacs and anything that follows its key bindings very often as well for incremental search forward. (It's not used in the shell even though that typically implements emacs bindings, because there you usually want to incrementally search backward, i.e. C-r.) I think C-z is the perfect candidate for the reasons you mentioned.
Left arrow is not where my fingers are, but ctrl-b is.
I would have to move my whole hand over to the arrow keys, or I can use the edge of my right hand (on a full size keyboard, not laptop) to hit ctrl, and hit "b" with my left index finger.
I use F2. Unlike the arrow keys, I don't have to move my hands and I can hit it reliably. I use it enough that I want it within reach, but not so often that I need it on the home row, and all Ctrl combinations there are already tied to emacs operations in my mind.
Same reasons you might need Ctrl-a instead of Home...
1) Some keyboards don't have it, or have it in an awkward place. Most Android on-screen keyboards don't have it (good time to plug Hacker Keyboard). The gestures on Blackberry (e.g. Android) physical keyboards act like scroll-wheel movements rather than cursor keys.
2) Some shells/systems/terminal emulators/some TERM= settings/etc. just don't handle cursor or home/end keys in the console, and instead splat out garbage like: ^[[C^[[D^[[7~^[[5~
What, and move my entire hand to the far side of the keyboard like some sort of savage? (But seriously, I actually do prefer avoiding moving my hands for ergonomic reasons.)
You should do whatever you want with your hands, but you should be aware that not moving your hands is bad for ergonomics. It promotes static posture and staying in one position for too long can cause muscle stiffness and strain. Moving around promotes blood flow and reduces fatigue. Consistent doing a small set of motions (ie never moving your hands) is what leads to RSI.
Of course, a bad setup is a bad setup, and if you're moving your hands a lot because your workspace is poorly setup, you'll also have issues.
For best results, you'll want to keep your hand movements natural and comfortable and your tools within easy reach. Take short breaks to move your hands, as well as your entire body.
What about effortless manipulation? I have CapsLock as Control and shell manipulation has become easier with readline keybinds. I can touchtype but, the extra keys are always at a different place so I don't bother learning their emplacement. So I rest my hands, but I prefer those keybinds because the already short typing bust is even shorter.
I find most of shellcheck's opinions quite arbitrary.
Wider shell compatibility is a good reason to use backticks. Avoiding nesting is always possible. Quoting may be a concern in more complex usage. But yes, I know well, and often also use $( ) syntax.
Making a lot of noise about use of (the shellcheck author's) non-preferred syntax, which works perfectly fine in a given context, is a design flaw that renders shellcheck useless to me. I'm perfectly capable of finding an opinionated pedant on my own who will also critize the syntax I use (with little or no justification), and offer no actual help...
I’ve heard of Zellij before but never got a chance to try it. My main use of tmux is with a Synology NAS to run some long running commands where I don’t have to retain the ssh session until completion. Unfortunately, Zellij doesn’t seem to be available as part of the community packages. [1]
Every time the connection blips you lose the shell.
Very annoying.
Look up how to prevent that.
Learn about tmux.
Use tmux on remote shells to keep sessions up after you log out.
Neat.
Apparently tmux has sessions and panes and stuff, I could have multiple projects open in different sessions. I could have different logs and commands running in different panes.
Neat.
Hey, this is great. I should install tmux on my personal machine.
Hey, I love having multiple sessions and panes and stuff, but now when I reboot my computer, all my tmux sessions and panes are gone.
Learn about tmux-resurrect and tmux-continuum which will save the sessions periodically and automatically reconstitute them after reboot.
Extremely neat.
~10 years later and I still have all the "same" tmux sessions open, and they all have names, saved pane layouts, and histories intact.
Similar journey for me except the persisting sessions.
When i encounter repetitive/manual state i need to circle back to, ill make scripts or custom configs to replicate it (nix is fantastic for that). My workflow allows sessions to close on disconnect or shutdown which brings the benefit of not relying on remote tmux installations.
Chances are, you carry around alot of implicit state. How do you backup?
tmux-resurrect/tmux-continuum + atuin for shell history saves pretty much any terminal state I've ever needed, I think, outside of .zshrc and the like.
Thank you. I sometimes put off reboots longer than I should simply because I don't want to lose my local tmux sessions. Maybe I don't have to do that anymore.
My story is very similar, still using tmux on servers and my workstation. But I know a lot of people or colleagues that don't use SSH in the first place, which made them miss the first step.
sure -- tmux is very much so crucial to my dev workflow, which is primarily a terminal-based dec env: nvim + lsp + daps + snippets + other extensions that are useful for dev.
i have splits for dev, splits for building and testing, splits for sandboxing -- it allows me to multi-task with more screen real estate than using something like vscode or vstudio or some other conventional IDE.
Note that I have been using text-only terminals since the 1980s, but I've adapted my tty usage over time.
The problem that tmux (or screen) brings are first and foremost:
* Smooth/fast scrolling goes away. I can no longer give my trackpad a slight push to find myself tens or hundreds of lines in the scrollback history, and visually scan by slightly pushing my fingers back and forth. Instead I have to use the horrendous in-tmux scrollback using "Ctrl-b [".
* My terminal app's tabs and windows are not tmux's tabs and windows. I cannot freely arrange them in space, snap them off with the mouse, easily push them to another desktop, and so on. I have to start a multiple tmux clients and do awkward keyboard interactions with them for any of the same.
* tmux's terminal emulation and my terminal emulator's terminal emulation (heh) are not congruent. As a result, programs cannot make full use of my actual terminal's capabilities. For example selecting, copying, and pasting text sometimes behave weirdly, and there are other annoyances.
What I'd really like to have instead is terminal session management at a higher level, i.e. involving my actual graphical terminal app itself. Attaching to a running session would mean restoring the terminal app's windows and tabs, and the entire scrollback history within (potentially with some lazy loading).
tmux could likely be a major part of that, by providing the option of replacing its tty-facing frontend with a binary protocol that the graphical terminal app talks to, while keeping the backend (i.e. the part that provides the tty to anything running inside it) the same as it is today.
As it is, the downsides of using tmux all the time are too high.
reply