Both screen and tmux do this, and if you’ve never tried either of them please do!
Much easier to deal with “tabs” in a single terminal session, plus you can detach a session and reattach it later. Screen also has a nice feature that lets you essentially share a terminal session by reattaching it multiple times without disconnecting the other sessions (screen -x).
Pretty sure you can attach to an already attached tmux session as well, which I believe has the same behavior that you’re describing. I’ve never used screen, is what you’re describing different than what I’m talking about?
The default behavior of tmux when multiple users are attached to the same session is that each user shares the same active window. With screen users can choose the active window independently of others.
You can get similar behavior in tmux by creating a new session with the "group-name" argument set to that of the name of the session you want to attach to.
in tmux a window can be in multiple sessions. but tmux also can switch between sessions easely as switching windows. if you want to connect to the same session multiple times, you need to either set that up, or you can create and use multiple sessions to the same effect.
having all windows in a single session synchronized is helpful when you share sessions with other users.
I need a cheat sheet to use tmux. I've no doubt I'd find it valuable if I spent some time learning it, but I can also appreciate this thing for adding a nice function without changing the way I work. Not a dig at tmux!
there are plenty of tutorials to get you started, but most importantly you can run tmux without having learned any of it.
start it and continue working as if it wasn't there. then read or learn one thing or two about it, and use only that.
the first thing to learn is how to attach to an existing session. that alone can be useful.
if you scroll a lot on your terminals, you'll want to learn scrolling in tmux.
if you use tabs or multiple windows, you' want to learn how create and switch windows in tmux.
beyond that every feature in tmux is additional to your regular terminal use so you can pick and choose the features you want to learn as you go along and otherwise continue without changing the way you work.
i have used tmux for a decade and i am still learning new stuff, like how to effectively use split windows.
Anyone who would not benefit from tmux must only very rarely use the terminal, or not at all.
This isn't a dig at this tool, just a strong endorsement for tmux =)
I use the terminal for almost everything but rarely use tmux, I have a window manager for window management so tmux doesn't really seem too useful in that regard
A huge benefit of tmux is session management, where you can resume a session on a different terminal. I use it on my desktop, so I can ssh in on my laptop when working from home, and immediately pick up where I left off.
Actually yeah you are right. I use tmux for running a doom server with my friends. Sorry I forgot about that because I don't generally need to log into it
Ahh, I said such in tongue and cheek. Indeed, I recently had need to communicate via serial console and searching Stackoverflow suggested screen. I tried tmux and... nope.
I ended up using `minicom` instead.
Alas, serial ports are pretty nifty but I get the impression that they are distinctly becoming a lost art
Do you ever ssh into remote servers?
Tmux would give you that same pane management on a remote server without having to SSH into the server in each pane.
He probaly means tiling window manager specifically, which makes tmux's binary partitioning redundant for all but remote work.
I used to use tmux much more heavily locally before I switched to a tiling window manager, now I only use it when I need to do a lot of work over SSH or am using an unstable connection or long running process etc.
Since I moved exclusively to i3 some 10 years ago, I find myself seldomly using screen/tmux anymore.
The splitting, moving and switching of windows is just more convenient.
Tmux has been relegated to start long running processes on remote servers, and remote pair programming sessions.
I could see myself using tmux more if I could find a way to get a more seemless experience when having to scroll panes, copy/paste, handle $TERM properly with vim (I always end up with partially refreshing vim colors under tmux), etc
the main advantage for tmux is in remote use. i work on multiple machines (laptop, desktop, etc) and i often like to access one from the other. tmux allows me to switch devices in a seamless way. i don't use i3 but you are right about the splitting in particular. it would be nice if we could have more gui integration of tmux. like a graphical tmux client that maps split windows to resizeable gui panes
I only had a quick glance at the source code and my Go is terrible so forgive me if I've misunderstood something.
But am I right in the assumption that this includes a proxy that acts as a sort of "middleware" layer for the terminal without explicit support from either the shell or the terminal?
If so, this might have a lot more potential than it seems. Imagine how much you could do with "terminal middleware"!
Tmux could be seen as an example of "terminal middleware" but I mean a more general solution.
Imagine you had a framework that lets you write scripts to intercept and modify I/O from programs running in a shell. You could have password managers that automatically (or semi-automatically) answer sudo prompts. Or filters that censor certain strings (if you're live streaming coding sessions this could be very useful) before they appear on screen.
Another useful "terminal middleware" layer could be pre-processing commands before (or after) the shell parses them. You could wrap every command in a `script -c` invocation in order to capture the output so that you can later re-use it without having to redo the processing. (This is probably my biggest pet peeve with Un*x since it really adds up over time.)
There's a spectrum of these. There's terminals that have their own modes, like Termite. There's also terminals that have their own scripting/extension frameworks, like hyper.js or secureCRT.
My personal favorite is Emacs. It's the only environment I've ever been able to rig up that's truly, fully hackable. Since terminal output is treated like any other text buffer, I can roll just about any package I like on top without issue.
In particular, this solved my ssh woes. There's no need to reconfigure my terminal dozens of times each day, because all my preferences and tweaks exist on a higher layer.
why is there nothing that shows what this does on the project page? You've spent countless hours creating this thing, yet you can't spend 10 more minutes showing off the capabilities?
you have a static PNG image that is confusing at best. create a 15 second animated GIF that shows off your work.
I thought the static PNG was just fine, personally. What would an animated GIF show here, the time changing every 60 seconds? Animated product showcases are just annoying to me because I can't study any particular scene long enough to see everything.
There could be some explanation which part of the static PNG is relevant. Like a an arrow pointing to the bar with some text "Look here". Not everyone knows terminals and shells well enough.
So this puts some basic information into every terminal, and there is no way add your own information? Why not use the normal Bar from your windowmanager or desktop environment?
I could understand it if you can personalize the bars per terminal, and show some context-specific informations. Stuff like git-branch, hostname, docker-container or active virtual environment, which usually ends in the prompt and is more of a waste to be located there. But there seems to be no way for scripting this?
Neat! I rarely mess with my prompt but actually now that I've seen this seeing things like CPU especially in a development context could be quite useful.
No, it has been demonstrated that servers can detect whether a request is being downloaded or piped to a shell, so they can vary the response accordingly, sending safe-looking content to a user who's inspecting it, and sending malicious content to a shell.
For iTerm users, there's a built-in feature that works very well: https://www.iterm2.com/documentation-status-bar.html