The tmux default is C-b which hasn't yet conflicted with anything for me (and I am very keyboard oriented). But the other suggestions might be just as good or better.
I'm probably the minority, but I don't see the point of terminal multiplexers.
I do see the point of reattaching to shell sessions or attaching from multiple devices.
But I already have a window manager that can manage multiple windows. I can reattach to as many sessions as I like and use my window manager to move them around. I don't see why I would want another window manager inside of an application. These nested window managers just seem to add complexity.
Yes, they only thing I ever use one for is reattaching to sessions.
I think the reasoning is that the client terminal could change, so the multiplexer ‘must’ emulate a terminal. However, my client terminal type in fact does not ever change, and I would prefer to have it available rather than the multiplexer's half-baked emulation.
By ‘emulating’ I don't mean providing a pty, I mean providing a terminal emulator in the usual sense of interpreting control sequences to maintain a screen representation. Dtach and abduco (which I only learned about from this thread) does the former only, while tmux and screen do both.
I'm in the same boat and like abduco [0], which does exactly session {de,re}attaching and not more. The author suggests to pair it with dvtm (terminal multiplexer without session {de,re}attaching), but of course just using a window manager works just as well.
Every time a post about multiplexers comes up, there is a comment like this. I find it striking that so many people think that their use-case is the only one, and don’t make any effort at all to imagine other cases where the situation might be different.
It’s really not that big if a stretch to see how they would be useful or even necessary when accessing servers (or any machine) remotely. You can have multiple shells and multiple things running, without having to re-login for each separate thing. And for critical processes you need to run, you want some protection to stop them getting killed if there’s a network problem.
1. I never said "they shouldn't exist" or are useless. I just said that "I" don't see the point.
As for multiple shells I just use SSH multiplexing and keep my tmux sessions having one window each. Then I can regroup or reorganize however I wish and still use the same window manager. But I use an SSH key anyways so logging in again is transparent. (The multiplexing just speeds it up a tad)
> And for critical processes you need to run...
I explicitly said that I understand the benefit of reattaching. I just personally don't find a use case for the multiplexing part.
I'm using tmux in Azure Cloud Shell all the time. Start long running helm command, split pane, monitor progress with kubectl. If command takes too long to run and shell disconnects, chances are tmux attach will get me back to where I was.
1) For me, I don't really do anything fancy with my window manager(s) and consider my work mostly terminal oriented. So I want a workflow that isn't dependent on what terminal emulator or operating system i'm on locally.
2) If i'm shelled into a system I just want to open another pane quickly to look at something, not open a new window, ssh, then move to that directory.
3) I get tired of configuring things to work the way I like. If I can copy my vim and tmux config, I know I can get to work and be comfortable. I don't have to worry about making different different OSs and terminal emulators act the same. I want my coding workflow/muscle memory to be based around things running in the terminal, not a mix of terminal and non-terminal/local things. It seems more unix philosophy oriented to me.
4) I can move from office to lab or go home and pick up right where I left off without any remote desktop nonsense.
I use tmux a lot at work because it allows me to do multiple tasks at once over ssh. Also, the synchronize-panes function is incredible for configuring multiple servers identically at the same time, which is a task I perform on a weekly basis. And of course, the ability to reconnect to a session is excellent as well.
There are some dueling abstractions, yes! There was a good write-up from Anil Dash that picked up one of my favorite pieces of the recent TabFS write-up[1][2], _Keeping Tabs on Abstractions[3],_ noting that the browser & OS are each running competing abstractions for tabs. The application's invention of the Multi Document Interface (MDI) has done weird things! And I feel like most consumer OSes have done little to try to unify or provide options in the OS level, to take back territory.
I as quite happy & pleased when Google's Chrome on Android had tabs each appear as tabs in the OS. I have too many tabs, but I enjoyed that it was up to my launcher, up to my os to help me work with that. It gave me flexibility & options to approach the problem. Where-as, when Chrome went back to managing tabs itself, it's both been a disaster for me (new tab window shows me the start of my tabs, which has some years old tabs i only need occasionally), and a sadness, a defeat, that the OS can no longer manage this thing.
> I do see the point of reattaching to shell sessions or attaching from multiple devices.
I've recommended dtach[4] elsewhere[5] in this topic & here-by recommend it again! Very lightweight detachable proxy for persistent programs. I run vim inside of it, so I can attach/detach. Vim has terminals inside of it, so that's all I needed.
The Chrome is an interesting example because it seems that some people liked it but it was arguably a bit of a botched implementation. (It seems like when Chome was killed and opened again it would put all of the tabs at the front, instead of sorting them by the time each tab was last used). Also people were complaining about no longer being able to swipe between tabs, but with Android gesture navigation this shouldn't be an issue anymore.
I'll take a look at dtach too. I think one of the benefits of using tmux just for reattaching is that tmux is widely used and tested against all sort of shell escape codes. I have a slight worry that the less popular tools will not handle all of the cases as gracefully. I'm hoping that I am wrong though and it works well.
> I feel like most consumer OSes have done little to try to unify or provide options in the OS level
Yeah, I've always thought it was weird that the X11 window management protocol wasn't extended to accommodate native tabs, so it's always handled in-client.
> I've recommended dtach
dtach is great! I've always wondered why people were so enamored with screen and tmux, when I don't really want a second, full-fledged terminal emulator running inside my desktop terminal emulator—I just want to detach from sessions. Most importantly, though, I want this to be baked in, ideally at the system level, but would settle for dtach-like integration with gnome-terminal; whatever allows this to be done lazily, without needing the foresight to use dtach from the beginning—just like you're not required to specify ahead of time whether you want to use job control (Ctrl-Z) at the time that you start the process.
It's a big shame. Two examples of natural growth with high utility that have just never happened, because we're supposed to stay stuck at the state things were in in the early 90s or something.
I run multiple terminal sessions on a remote box over a single SSH connection through a bastion server. I have an editor in one tab and run my Ansible playbooks Git commands in another, tail logs in a third, etc. You could totally do this in multiple SSH sessions but this is more convenient for me. Byobu made remoting a lot more convenient.
For switching around quickly among multiple xterm instances that I keep running, all the time, and searching history. I used to heavily use konsole but found that switching to xterm + tmux was lighter-weight (fewer extras to install), fast, and very flexible. It took a while to get everything set up the way my muscle memory wanted, but after time working through the manual pages and a few web searches (over time) I'm very happy.
I use customized keys for navigating easily around many tmux windows where I like the low overhead so it doesn't break my train of thought).
And with tmux panes: it's great occasionally to be able to send the same keystrokes simultaneously to all panes, like to multiple remote hosts). Something like a similar konsole feature, or a variant of pdsh+dshbak.
That and fvwm (also customized) make it so I can get where I want between tasks or apps with the fewest keystrokes I've found so far.
Edit: that plus that tmux allows scripting, such as to set things up for me automatically after rebooting, in ways that I'm not sure how I would do with shell scripts -- it has added another sphere of automation that I didn't have before -- maybe similar to what one could get with the expect language -- like simple automation inside both shells and apps running in them. Plus more features it has that I haven't tried yet. It is really rich.
Another possible benefit from tmux is that it is originally developed as part of, and included in OpenBSD's base distribution, so it hopefully gets the kind of attention and high standards for quality and security as the rest of that OS (like OpenSSH in that regard). (This is not to criticize the other products in this space -- they may be excellent also.)
Personally, I really value the fact that tmux has a nice, clean api to manage windows and panes. I have a few scripts which run a bunch of tmux commands to create new windows with multiple panes for logging/consoles/source code for an individual service. Being able to use send-keys(http://man.openbsd.org/OpenBSD-current/man1/tmux.1#send-keys) has been amazing for automating things like this. I'm sure that other tools that I'm not aware of can do this sort of thing, but I find it to be quite productive.
Really nice cheat-sheet write up on screen & tmux & byobu.
Also worth checking out tabs-rs[1] which seems very well reviewed & recent.
Personally, I am a huge fan of dtach[2][3], which isn't a multiplexer, just a detachable proxier of terminal sessions. This let's me run a persistent vim session that I can reconnect to, and vim has however many terminals I need open in it. Vim does my multiplexing, dtach just allows me to make vim persistent. Very glad to have re-discovered dtach, to enable this workflow.
Notably dtach is very lightweight. Unlike tmux, it is not a virtual terminal. Upon reconnect to my vim session, I issue a control-l to refresh the screen. Dtach hasn't retained the screen state, isn't translating between terminfos. The one thing that can go wrong here is connecting from different terminals- few programs have a way to update the TERM setting once the program has launched.
Terminal multiplexers are useful, but they should be integrated in the terminal emulator. Disclosure: I'm the author of DomTerm (https://domterm.org) which does that. Having a multiplexer emulate a terminal on top of a terminal emulator is wrong in multiple ways. Most obviously you're limited to the functionality that is common to both the multiplexer and the underlying terminal. The user interface is restricted: You can't re-arrange sub-windows with the mouse (drag). Menus aren't integrated. You have to use a special command-key that applications may not use. (With an integrated multiplexer you can use a command-key that applications can't use because it doesn't send an xterm escape sequence.) Different sub-windows can connect (and detach/re-attach) to different remote servers without explicitly running nested remote multiplexers etc.
I believe DomTerm can conceptually do everything that GNU screen or tmux can do, in a more integrated way. I say "conceptually": It has the major features but is missing some polish and minor features because it is less mature. (Help welcomed.) I'm current working on polishing "copy/view mode". The way DomTerm handles remote connections (http://domterm.org/Remoting-over-ssh.html) is mostly done and if-I-say-so-myself quite elegant and user-friendly.
> You can't re-arrange sub-windows with the mouse (drag).
Just a nit-pick:
You can configure that with tmux (and possibly screen, I don't know). It has the downside that the user needs to know to press shift while clicking when they want to route mouse actions to the terminal emulator (e.g. to select text) instead of tmux or the applications running inside of it.
35 comments
[ 2.9 ms ] story [ 78.2 ms ] threadC-a has always driven me nuts because it’s emacs/readline for “beginning of line”.
I’ve settled on C-o for a while but sometimes that gets in the way too.
I haven't checked, but if multiplexers don't already use XTMODKEYS to allow more complicated prefixes, they should.
C-Space for tmux.
Especially with Ctrl bound to Caps-lock.
It's really C-o but I have that key combo mapped to C-; and capslock -> C when pressed with another key (otherwise defaults to esc)
Pinkies all the way
I do see the point of reattaching to shell sessions or attaching from multiple devices.
But I already have a window manager that can manage multiple windows. I can reattach to as many sessions as I like and use my window manager to move them around. I don't see why I would want another window manager inside of an application. These nested window managers just seem to add complexity.
I think the reasoning is that the client terminal could change, so the multiplexer ‘must’ emulate a terminal. However, my client terminal type in fact does not ever change, and I would prefer to have it available rather than the multiplexer's half-baked emulation.
In the first window, I have IRC, in the second a Twitter client, and in the following whatever random stuff I'm hacking on at the moment.
This means I can keep online from wherever I have an ssh session. Very convenient!
[0] https://www.brain-dump.org/projects/abduco/
It’s really not that big if a stretch to see how they would be useful or even necessary when accessing servers (or any machine) remotely. You can have multiple shells and multiple things running, without having to re-login for each separate thing. And for critical processes you need to run, you want some protection to stop them getting killed if there’s a network problem.
As for multiple shells I just use SSH multiplexing and keep my tmux sessions having one window each. Then I can regroup or reorganize however I wish and still use the same window manager. But I use an SSH key anyways so logging in again is transparent. (The multiplexing just speeds it up a tad)
> And for critical processes you need to run...
I explicitly said that I understand the benefit of reattaching. I just personally don't find a use case for the multiplexing part.
If you meant “I personally don’t use this feature but I can see how others would find it useful”, then that is not what is meant by that phrase.
2) If i'm shelled into a system I just want to open another pane quickly to look at something, not open a new window, ssh, then move to that directory.
3) I get tired of configuring things to work the way I like. If I can copy my vim and tmux config, I know I can get to work and be comfortable. I don't have to worry about making different different OSs and terminal emulators act the same. I want my coding workflow/muscle memory to be based around things running in the terminal, not a mix of terminal and non-terminal/local things. It seems more unix philosophy oriented to me.
4) I can move from office to lab or go home and pick up right where I left off without any remote desktop nonsense.
I as quite happy & pleased when Google's Chrome on Android had tabs each appear as tabs in the OS. I have too many tabs, but I enjoyed that it was up to my launcher, up to my os to help me work with that. It gave me flexibility & options to approach the problem. Where-as, when Chrome went back to managing tabs itself, it's both been a disaster for me (new tab window shows me the start of my tabs, which has some years old tabs i only need occasionally), and a sadness, a defeat, that the OS can no longer manage this thing.
> I do see the point of reattaching to shell sessions or attaching from multiple devices.
I've recommended dtach[4] elsewhere[5] in this topic & here-by recommend it again! Very lightweight detachable proxy for persistent programs. I run vim inside of it, so I can attach/detach. Vim has terminals inside of it, so that's all I needed.
[1] https://omar.website/tabfs/
[2] https://news.ycombinator.com/item?id=25600338
[3] https://anildash.com/2021/01/03/keeping-tabs-on-your-abstrac...
[4] https://github.com/crigler/dtach
[5] https://news.ycombinator.com/item?id=25792205
The Chrome is an interesting example because it seems that some people liked it but it was arguably a bit of a botched implementation. (It seems like when Chome was killed and opened again it would put all of the tabs at the front, instead of sorting them by the time each tab was last used). Also people were complaining about no longer being able to swipe between tabs, but with Android gesture navigation this shouldn't be an issue anymore.
I'll take a look at dtach too. I think one of the benefits of using tmux just for reattaching is that tmux is widely used and tested against all sort of shell escape codes. I have a slight worry that the less popular tools will not handle all of the cases as gracefully. I'm hoping that I am wrong though and it works well.
Yeah, I've always thought it was weird that the X11 window management protocol wasn't extended to accommodate native tabs, so it's always handled in-client.
> I've recommended dtach
dtach is great! I've always wondered why people were so enamored with screen and tmux, when I don't really want a second, full-fledged terminal emulator running inside my desktop terminal emulator—I just want to detach from sessions. Most importantly, though, I want this to be baked in, ideally at the system level, but would settle for dtach-like integration with gnome-terminal; whatever allows this to be done lazily, without needing the foresight to use dtach from the beginning—just like you're not required to specify ahead of time whether you want to use job control (Ctrl-Z) at the time that you start the process.
It's a big shame. Two examples of natural growth with high utility that have just never happened, because we're supposed to stay stuck at the state things were in in the early 90s or something.
I do see the point of them on remote machines
I use customized keys for navigating easily around many tmux windows where I like the low overhead so it doesn't break my train of thought).
And with tmux panes: it's great occasionally to be able to send the same keystrokes simultaneously to all panes, like to multiple remote hosts). Something like a similar konsole feature, or a variant of pdsh+dshbak.
That and fvwm (also customized) make it so I can get where I want between tasks or apps with the fewest keystrokes I've found so far.
Edit: that plus that tmux allows scripting, such as to set things up for me automatically after rebooting, in ways that I'm not sure how I would do with shell scripts -- it has added another sphere of automation that I didn't have before -- maybe similar to what one could get with the expect language -- like simple automation inside both shells and apps running in them. Plus more features it has that I haven't tried yet. It is really rich.
Another possible benefit from tmux is that it is originally developed as part of, and included in OpenBSD's base distribution, so it hopefully gets the kind of attention and high standards for quality and security as the rest of that OS (like OpenSSH in that regard). (This is not to criticize the other products in this space -- they may be excellent also.)
Also worth checking out tabs-rs[1] which seems very well reviewed & recent.
Personally, I am a huge fan of dtach[2][3], which isn't a multiplexer, just a detachable proxier of terminal sessions. This let's me run a persistent vim session that I can reconnect to, and vim has however many terminals I need open in it. Vim does my multiplexing, dtach just allows me to make vim persistent. Very glad to have re-discovered dtach, to enable this workflow.
Notably dtach is very lightweight. Unlike tmux, it is not a virtual terminal. Upon reconnect to my vim session, I issue a control-l to refresh the screen. Dtach hasn't retained the screen state, isn't translating between terminfos. The one thing that can go wrong here is connecting from different terminals- few programs have a way to update the TERM setting once the program has launched.
[1] https://github.com/austinjones/tab-rs
[2] https://github.com/crigler/dtach
[3] https://wiki.archlinux.org/index.php/Dtach
I believe DomTerm can conceptually do everything that GNU screen or tmux can do, in a more integrated way. I say "conceptually": It has the major features but is missing some polish and minor features because it is less mature. (Help welcomed.) I'm current working on polishing "copy/view mode". The way DomTerm handles remote connections (http://domterm.org/Remoting-over-ssh.html) is mostly done and if-I-say-so-myself quite elegant and user-friendly.
Just a nit-pick:
You can configure that with tmux (and possibly screen, I don't know). It has the downside that the user needs to know to press shift while clicking when they want to route mouse actions to the terminal emulator (e.g. to select text) instead of tmux or the applications running inside of it.