Show HN: Shpool, a Lightweight Tmux Alternative(github.com)
github.com
Show HN: Shpool, a Lightweight Tmux Alternative
https://github.com/shell-pool/shpool
shpool is a terminal session persistence tool developed internally at google to support remote workflows, which we have open sourced.
200 comments
This is awesome! I hate the way tmux hijacks so much of my terminal's behavior (scrollback, seaching with escape-/, etc.) and I've been looking for something like this that will manage persistent sessions without any extra nonsense.
BTW I think your readme shouldn't just characterize it as a resumeable ssh tool. I often need to start a long running process that I want to reconnect to later, or I want to put some always-on system service inside a tmux container so I can easily jump in and see logs or mess with things in one way or another. There's a lot of utility besides just handling network dropouts.
BTW I think your readme shouldn't just characterize it as a resumeable ssh tool. I often need to start a long running process that I want to reconnect to later, or I want to put some always-on system service inside a tmux container so I can easily jump in and see logs or mess with things in one way or another. There's a lot of utility besides just handling network dropouts.
The thing is that without hijacking it and passing it through, you can't have nice things like handling resizes, supporting attaching with multiple terminal emulators, or reconnecting to applications that make heavy use of terminal escape codes, because all of those set up persistent state in the terminal emulator.
As a result, any tmux-like layer needs to emulate a console in order to get a view into the state, and then re-render that emulated console on attach to restore state to the terminal emulator that you're connected from.
From the readme, this tool does that, kinda. I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it, and yet not bother with doing the work that would let multiple terminal emulators attach.
This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.
As a result, any tmux-like layer needs to emulate a console in order to get a view into the state, and then re-render that emulated console on attach to restore state to the terminal emulator that you're connected from.
From the readme, this tool does that, kinda. I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it, and yet not bother with doing the work that would let multiple terminal emulators attach.
This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.
You definitely don't need the in-memory terminal emulator to handle resizes or allow attaching with multiple local terminal emulators, since dtach does both and does not have an in-memory terminal emulator.
> I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it
Well, we kinda cheated here. shpool_vt100 is just the already existing vt100 crate with a single critical bug fixed, so it actually wasn't much work :). Turns out having a nice package manager for a systems language comes with some benefits.
I'm actually open to adding a feature to allow multiple simultaneous connections to a single session. I never really had a usecase for it personally so I haven't prioritized it, but it is something that similar tools support and people keep bringing up. Since this isn't the first time I've heard people talking about it, I just made https://github.com/shell-pool/shpool/issues/40 to track work adding the ability to attach multiple clients to the same session.
> This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.
I'm not aware of any tool that does internal rendering and subsetting handling scrollback and copy-paste in a way that I personally find usable, so these decisions were very much intentional.
I think tmux is a great tool for a lot of people, and I tried to get into it for years, but I could just never get over the weird scrollback and copy-paste issues or the fact that it meant that I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session. If tmux works for someone, I think that's great and they should keep using it. shpool is meant for people like me who aren't very good with computers :).
> I'm actually confused about why they'd go to the effort of implementing a VT100 emulator, write the code to redraw the screen from it
Well, we kinda cheated here. shpool_vt100 is just the already existing vt100 crate with a single critical bug fixed, so it actually wasn't much work :). Turns out having a nice package manager for a systems language comes with some benefits.
I'm actually open to adding a feature to allow multiple simultaneous connections to a single session. I never really had a usecase for it personally so I haven't prioritized it, but it is something that similar tools support and people keep bringing up. Since this isn't the first time I've heard people talking about it, I just made https://github.com/shell-pool/shpool/issues/40 to track work adding the ability to attach multiple clients to the same session.
> This feels like it sits in a weird place between simple, crude tools like dtach, and tools like tmux; shpool has done most of the work to implement tmux-style behavior, and then decides to cut weird corners.
I'm not aware of any tool that does internal rendering and subsetting handling scrollback and copy-paste in a way that I personally find usable, so these decisions were very much intentional.
I think tmux is a great tool for a lot of people, and I tried to get into it for years, but I could just never get over the weird scrollback and copy-paste issues or the fact that it meant that I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session. If tmux works for someone, I think that's great and they should keep using it. shpool is meant for people like me who aren't very good with computers :).
I’m not sure what the popular use case is for multiple connections to one multiplexer. But, two (niche seeming) ones could be: if you have a desktop, you want to be able to SSH to it and use it locally at the same time. Or, if you have two people ssh-ing to one system, and letting them share a terminal might be nice (although in that case it would really be nice to give them independent cursors, which starts to become an involved project).
I usually have a drop down terminal that I use the most, then a full screen window on some other space. I can switch between them quickly and connect to any of my sessions from either.
Or one person ssh'ing to the same remote from two or more devices. If I don't feel like sitting in the office (desktop) and grab the laptop and go to the sitting room or back deck I can continue my session without issue, and then transition back later. I don't want to have to disconnect/detach a session when I do this, I want it to be seamless so both connections (actually three typically, an iPad as well) are running continuously.
we do use multiconnections when doing interviews - candidate solving test case on VM, interviewers are observing. Idea was not to confuse candidates by requiring screensharing during the interview, just see the particular ssh session.
Hi.
Nice kit.
> I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session
Just curious, what are your normal 'i3'/'sway' bindings that you cannot get to work with tmux ? And what actual terminal program do you use ?
Perhaps tmux wants more config than most people care to bother with, but scrollback and copy-paste can be configured just as you like.
If you’re using a tiling window manager your window switch keybindings necessarily conflict between the manager and tmux, since if you configure the same one and then press it while focused on a tmux window, the tiling window manager will override tmux and claim the event.
Scrollback and copy paste cannot always be configured as you want. I’ve shared some specifics elsewhere in this thread.
Scrollback and copy paste cannot always be configured as you want. I’ve shared some specifics elsewhere in this thread.
Hi.
ok, I get that. Maybe something like A-left to move to next i3 window and A-S-left to move to next tmux window within an i3 window ? Perhaps a tiling window manager with multiple windows combined with tmux dividing some of those windows further into sub-windows isn't an ideal flow.
It's not i3/tmux, but a similar problem exists for vim/tmux, where the vim window management keys will conflict with tmux's.
And there's https://github.com/numToStr/Navigator.nvim that unifies the keys by letting the outside layer (tmux) always ask the inside layer (vim) before any movements.
Although that is indeed a lot more setup. But works pretty well.
And there's https://github.com/numToStr/Navigator.nvim that unifies the keys by letting the outside layer (tmux) always ask the inside layer (vim) before any movements.
Although that is indeed a lot more setup. But works pretty well.
I think you would love zellij[1]. Go check it out, it is awesome.
1: https://zellij.dev/
1: https://zellij.dev/
I just started using this and it is indeed awesome. Only thing I need to figure out how to do is make a tab truly full screen. It's much nicer, more intuitive, has more built in support for things and is super lightweight. It's great.
Do you know mobile shell (mosh)? [1]
Seems like most of the features you need are what mosh offers. I've been using it for a decade, probably, and it is pretty awesome for latent mobile connections (read as: throttled 2G @16kBit/s with interruptions).
https://github.com/mobile-shell/mosh
Seems like most of the features you need are what mosh offers. I've been using it for a decade, probably, and it is pretty awesome for latent mobile connections (read as: throttled 2G @16kBit/s with interruptions).
https://github.com/mobile-shell/mosh
https://www.youtube.com/watch?v=XsIxNYl0oyU
> If you want to have 10 concurrent connections, you have to open 10 ports.
That is a problem in most environments.
> If you want to have 10 concurrent connections, you have to open 10 ports.
That is a problem in most environments.
I don't understand your statement, to be honest.
Either you waste lots of traffic bandwidth because you have to have a session identifier or nonce in every packet, or you have to map sessions to ports in order to guarantee persistance when the client drops its connection.
Other ways of doing session handling will lead to an attack surface that can probably be used for DoS attacks.
Maybe I am missing something: How would you solve this, given the limitations of UDP and TCP?
Either you waste lots of traffic bandwidth because you have to have a session identifier or nonce in every packet, or you have to map sessions to ports in order to guarantee persistance when the client drops its connection.
Other ways of doing session handling will lead to an attack surface that can probably be used for DoS attacks.
Maybe I am missing something: How would you solve this, given the limitations of UDP and TCP?
I am just saying that opening an unpredictable amount of ports is a problem for every firewall admin.
I think mosh first appeared in 2012? How can you have been using it for decades?
Sorry, mobile typo. Been using it since around 2013.
I once had a VPN utility that HAD to be closed with a Keyboard Interrupt in order for it to shut-off properly, so my systemd setup for it didn’t work. I ended up making bash aliases for tmux commands to run it and send the keyboard interrupt signal into it to stop it. I’m sure there was a way to do this with systemd, but tmux was easy, if a bit jank.
There's also the longstanding option dtach, which similarly seems to be a lightweight re-attachable way to run a program. https://github.com/crigler/dtach
For a while I was running neovim on dtach, which let me host all the terminals I might want. It has long felt weird that we have so recursively many layers of management and navigation: the OS juggling multiple terminals, tmux juggling multiple shells, and neovim juggling multiple windows. I was doing pretty good in full screen neovim for a while, but have backed down a bit, still find tmux navigation a bit faster.
For a while I was running neovim on dtach, which let me host all the terminals I might want. It has long felt weird that we have so recursively many layers of management and navigation: the OS juggling multiple terminals, tmux juggling multiple shells, and neovim juggling multiple windows. I was doing pretty good in full screen neovim for a while, but have backed down a bit, still find tmux navigation a bit faster.
The readme contains a brief comparison to dtach: https://github.com/shell-pool/shpool?tab=readme-ov-file#dtac...
IIUC, the main difference is that shpool maintains an in-memory copy of terminal state that it can use to re-draw after a reconnect, so you don't lose all your scrollback.
IIUC, the main difference is that shpool maintains an in-memory copy of terminal state that it can use to re-draw after a reconnect, so you don't lose all your scrollback.
dtach, abduco, and diss are all mentioned in comparison at the bottom of the page. I've never used diss before, but the other two are good products, but for some reason the ergonomics never quite seem to work out for me and I revert back to tmux.
Similarly dvtm, which is a minimalist version of the window management aspects of tmux but omits the session management, also never quite seems to click for me.
Similarly dvtm, which is a minimalist version of the window management aspects of tmux but omits the session management, also never quite seems to click for me.
> It has long felt weird that we have so recursively many layers of management and navigation: the OS juggling multiple terminals, tmux juggling multiple shells, and neovim juggling multiple windows
Tbh that's why I'm not a fan of tmux or terminals with fancy internal window management. I suppose it makes sense if your OS level window management is crap (macos...) but otherwise it feels like poor solution
Tbh that's why I'm not a fan of tmux or terminals with fancy internal window management. I suppose it makes sense if your OS level window management is crap (macos...) but otherwise it feels like poor solution
But tmux on server survives the laptop sleeping. That's the key value.
"if your OS level window management is crap (macos...)"
-- in which case Divvy is a great solution. YMMV, but IME, Divvy and iTerm2 cover 98% of the things I'd want to do.
-- in which case Divvy is a great solution. YMMV, but IME, Divvy and iTerm2 cover 98% of the things I'd want to do.
Besides persistence, terminal multiplexing is one of the greats things of tmux. If I'm programming on a remote machine I don't want to open a new ssh connection from each of the five terminals that I need. Seems tedious when I can just create a new window inside tmux. Even locally, I don't want to have 10 terminals opened (or tabs), tmux lets you have multiple terminal windows/panes from a single physical terminal and lets you easily group and switch between them into what they call sessions.
The problem is that because I use tmux so heavily locally, using it remotely is a pain in the ass.
My normal workflow is either to be sitting in front of my Linux machine, or SSH'd to it (from a Windows laptop). Tmux makes the transition between those two seamless. But nesting tmux doesn't work.
My normal workflow is either to be sitting in front of my Linux machine, or SSH'd to it (from a Windows laptop). Tmux makes the transition between those two seamless. But nesting tmux doesn't work.
Not sure, if it's a bug, but it eats 1.4G memory after running find for a few seconds, detaching, re-attaching and running find again.
Active: active (running) since Fri 2024-06-14 19:26:55 +05; 27s ago
Invocation: d84b9281e0f64a798c4e555836815036
TriggeredBy: ● shpool.socket
Main PID: 3895609 (shpool)
Tasks: 15 (limit: 154377)
Memory: 1.4G (peak: 1.4G)
CPU: 6.566s
CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/shpool.service
├─3895609 /usr/local/bin/shpool daemon
├─3895629 -fish
├─3895719 systemctl --user status shpool
└─3895720 pagerUnbundling tmux is a great concept!
Other tools that can overlap in use case are EternalTerminal and mosh which provide sessions that survive disconnects.
Other tools that can overlap in use case are EternalTerminal and mosh which provide sessions that survive disconnects.
Oh thanks for mentioning EternalTerminal. I should add it to the comparison section in the README. It looks like it is similar to mosh in that it does stuff at the network level whereas all these other tools are purely remote-machine side programs, but it seems like it is a bit simpler than mosh. From a scan of their docs it sounds like they have the local terminal do all the rendering the way `shpool` does and don't try to muck about with any sort of predictive rendering the way mosh does. Does that sound right to anyone knows it well?
I am currently using mosh and tmux together, it does seem like there's a lot duplication. It works great though, and mosh has actual roaming which is good for subways, VPN changes, etc.
For me, mosh and tmux are like socks and shoes.
Looks nice. One feature I'd like is a read-only mode. Sometimes I want to execute a long running process and be able to just watch it run without risking that I hit Ctrl C by accident. I was surprised to find that Screen doesn't support this, I guess probably tmux does. tail is fine but I don't always want to record a huge log file.
Have you tried https://tmate.io/ ? It's a fork of tmux that, on startup, gives you web links and ssh connection strings to connect to the session. For each connection method you get one adress for read-only access and one for normal access.
I always found tmux and screen clunky to use when all I wanted was the persistence so this project is right up my alley.
tmux/screen is a way of life.
This seems to suffer the same problem as abduco, which is, you better be reconnecting from the same terminal (don't change your termcap). Fine if working from a single machine.
I did notice they have a vt100 emulator, but it's only used for screen restore?
It seems the focus of the tool is for reconnecting from the same machine.
I did notice they have a vt100 emulator, but it's only used for screen restore?
It seems the focus of the tool is for reconnecting from the same machine.
Yeah reconnecting from different terminals is a pretty tricky problem to solve (and in fact can't be solved in general because of potential skew between the terminfo db on the client machine and the remote machine). The big problem is that once you launch a shell, there is no great way to change environment variables from outside that shell, so you can't change the value of TERM for a running shell. I have thought about trying some LD_PRELOAD tricks to try to be able to call setenv() from within the shell process itself, but this always struck me as something that would require a pretty big hack.
nohup is also useful for this situation, but a lot of people don’t seem to know about it!
As the sibling comments show, nohup does occasionally have sharp edges re: sharing/inheriting std* streams. I've also encountered inconsistencies when using nohup with lots of different users' shells (academics of wildly variable technical skill levels, shell environments/customizations, and opinionatedness levels): what, exactly, does it mean to be backgrounded per "&"? Does nohup+& sufficiently background all types of shell jobs (answer: no--and some of those jobs even make sense to use with nohup)? Can configs in {ba,z,da,k,fi}sh change the job control behavior so that "forgetting" jobs malfunctions under nohup (if that's possible, your users will do it, I've found--and then defend their bizarre choices until you give up and move on)?
In those cases, I've found dtach to be slightly more reliable than nohup. Frequently I'll try one and switch to the other. Less frequently, I'll correct users' configs/workflows that are necessitating the troubleshooting in the first place. Even less frequently, I'll dig into what was actually the issue :)
https://linux.die.net/man/1/dtach https://dtach.sourceforge.net/
In those cases, I've found dtach to be slightly more reliable than nohup. Frequently I'll try one and switch to the other. Less frequently, I'll correct users' configs/workflows that are necessitating the troubleshooting in the first place. Even less frequently, I'll dig into what was actually the issue :)
https://linux.die.net/man/1/dtach https://dtach.sourceforge.net/
Does nohup allow attaching back to the session? That seems to be the primary use case of shpool.
No, it doesn't let you attach back, it just keeps a command going after you've disconnected your session. But if you have good logging that might be good enough.
Or use GDB to change stdin/stdout of the nohup'd process to the current shell!
like reptyr[1] or retty[2] does?
[1] https://github.com/nelhage/reptyr [2] https://github.com/lkundrak/retty
[1] https://github.com/nelhage/reptyr [2] https://github.com/lkundrak/retty
Probably!
lol!
Nohup still attaches to the terminal's stdin/out/err. If the process is known to be non-interactive, redirecting to log files should be sufficient (tail -f to "reattach"). If it does expect interaction, creating a fifo file to redirect stdin from should work, but I've never tested it.
nohub doesn't attach nor redirect the stdin/out/err, it intercepts the HUP signal that apps receive when their controlling TTYs are disconnected.
Implying "tail -f $LOGFILE" is akin to tmux reattaching to a console is a stretch.
Implying "tail -f $LOGFILE" is akin to tmux reattaching to a console is a stretch.
The standard Unix version of nohup does in fact redirect the output/error streams if they would otherwise go to a terminal. https://pubs.opengroup.org/onlinepubs/009695299/utilities/no... / https://en.wikipedia.org/wiki/Nohup
I love tmux. I don't think this is a replacement for it. At most, for `screen`. I use tmux locally for my day to day work. I have different named sessions for different things I'm doing (switching back and forth) and I have multiple windows and panes. The best thing is that I can switch terminal emulators without having to learn any new keyboard shortcuts.
This is more of a `screen` replacement than a `tmux` replacement, yeah? Was hopeful for an actual replacement (no, not iterm) to tmux.
Aren't tmux and screen rather equivalent these days? How is an alternative to one, not an alternative to the other?
Shpool doesn't appear to allow for session sharing/remote pairing though?
Shpool doesn't appear to allow for session sharing/remote pairing though?
shpool doesn't allow splitting screens either! But I guess in my head, screen is largely for resuming a shell connection on a remote host while tmux is a window splitter.
Screen and tmux are almost the same these days. Screen used to not allow side-by-side splits, but it can do that too now.
It has allowed that for a long, long time.
Okay, but is it actually good?
Screen vertical split works fine.
Let me rephrase that -- is it good enough to use 100% of the time you're in a terminal? Cause that's what I do with tmux and it works phenomenally. Haven't had a similarly good experience with screen before, but I'm open to being wrong.
Both of them are both of those things.
I always get scared when I accidentally have two shell sessions visible at once in tmux. I immediately exit one. I suppose I should read a bit on it. When I want side to side comparisons I go to the shell running emacs and do it there (post vague because I never remember the different words for windows and panes and shells etc these different apps use.)
tmux has a server containing sessions containing windows containing panes. Screen has sessions, windows, and panes (which it calls regions).
I recently finally switched from screen to tmux and I found that it's pretty seamless (especially because I use vi keybinds in tmux still). Some machines at work don't have screen anymore.
I recently finally switched from screen to tmux and I found that it's pretty seamless (especially because I use vi keybinds in tmux still). Some machines at work don't have screen anymore.
Ok,makes sense. Using this terminology, I asked claude and found out how to move a shell from a standalone window to sharing 2 panes with another shell.
Incidentally, this "screen absent" is why you should always volunteer to help create base shells (programmatically via packer not by hand) - emacs and tmux are always there when I made the image.
Incidentally, this "screen absent" is why you should always volunteer to help create base shells (programmatically via packer not by hand) - emacs and tmux are always there when I made the image.
What's a base shell?
I don't make the image.
I don't make the image.
So, I ran `shpool attach foo`, and I got this:
shpool:foo foo@bar ~ $ shpool detach foo
printf: usage: printf [-v var] format [arguments]
-bash: "\033]0;%s@%s:%s\007": command not found
-bash: "${USER}": command not found
-bash: "${HOSTNAME%%.*}": command not found
-bash: "${PWD/#$HOME/\~}": No such file or directory
> The biggest advantage of this approach is that `shpool` does not break native scrollback or copy-paste.
tmux/screen do not break copy-paste. And that tmux/screen have their own scrollback is a feature.
The selling point for shpool is simplicity, which I appreciate. I need terminal multiplexing, but I might use shpool here and there.
tmux/screen do not break copy-paste. And that tmux/screen have their own scrollback is a feature.
The selling point for shpool is simplicity, which I appreciate. I need terminal multiplexing, but I might use shpool here and there.
> tmux/screen do not break copy-paste
Tmux breaks interacting with the clipboard so much that it has its own dedicated Wiki page dealing with all of the different issues and settings: https://github.com/tmux/tmux/wiki/Clipboard
Tmux breaks interacting with the clipboard so much that it has its own dedicated Wiki page dealing with all of the different issues and settings: https://github.com/tmux/tmux/wiki/Clipboard
It literally doesn't though. The wiki page is for copying tmux copy-mode's internal selection. The selection and copying mechanisms of the terminal emulator still work just as well.
This is absolutely awesome. For ages I have needed an alternative to mosh that did not require UDP -- I run every outbound connection over Tor, so I only have TCP transport available. This is an incredible improvement to my quality of life.
You might prefer Eternal Terminal as a TCP mosh alternative:
https://eternalterminal.dev/
https://eternalterminal.dev/
Why is this better then the old school "screen"?
answer to my question is on the description page of Shpool. Looks compelling.
----
The biggest advantage of this approach is that shpool does not break native scrollback or copy-paste.
I'd say the best part is not needing screen on the server.
If you have several servers and several people that like several multiplexers, you would need to install all of them in each server, and manage configuration etc.
However, you can have your own multiplexer and use shpool on a window to connect to a server. Done, you have your favorite multiplexer, with your configuration, and the only tool in the server is shpool
However, you can have your own multiplexer and use shpool on a window to connect to a server. Done, you have your favorite multiplexer, with your configuration, and the only tool in the server is shpool
I'm not following what the difference is between installing screen on the server and installing shpool in the server.
[deleted]
Oh, this might be the missing piece of the puzzle for me to get rid of tmux!
I've been using screen/tmux for a long time. Recently I switched to kitty[0] locally. I like kitty a lot! But I've been stuck with tmux on my servers for session persistence.
[0]: https://sw.kovidgoyal.net/kitty/
I've been using screen/tmux for a long time. Recently I switched to kitty[0] locally. I like kitty a lot! But I've been stuck with tmux on my servers for session persistence.
[0]: https://sw.kovidgoyal.net/kitty/
Years ago I had a boss who gave me a hard time for how much resources tmux was using on linux and said that it performed fine where it's developed natively (openbsd) but something in it was making it eat resources compared to screen on constrained linux systems. I wonder if this is still the case?
If he was an OpenBSD fan he might have been overly anti-Linux.
Nah we're both pretty knowledgable programmers who use both OSes and it was measurably clear
I run tmux on my server and it's the single biggest user of memory (about 30% larger than the long-running node app) and while there's a client attached it constantly shows >5% CPU usage. Given the amount of time I'm connected this dwarfs all other resource usage on my server with the possible exception of occasionally building updates for saturated that's not in the repos. In April, I finally closed out and restarted the entire session (which had been running for ~2 years at that point and was using ~300M RES compared to the current 150M)
what is going on with this submodule URI? https://github.com/shell-pool/shpool/blob/v0.6.1/.gitmodules...
I'm guessing based on the Change-Id in its commit message <https://github.com/shell-pool/shpool/commit/6cef5782e358716a...> this was exported from some internal Google repo but for the rest of the world it makes $(git clone --recursive) real mad
I'm guessing based on the Change-Id in its commit message <https://github.com/shell-pool/shpool/commit/6cef5782e358716a...> this was exported from some internal Google repo but for the rest of the world it makes $(git clone --recursive) real mad
[deleted]
Oh, thanks for catching this. I'll clean it up https://github.com/shell-pool/shpool/pull/43
[deleted]
This looks awesome, what a great simple idea. I like tmux, but native smooth scrolling is so much better. So is searching, copy and pasting.
Is it tested on macOS? Ready for use in production?
Thanks
Is it tested on macOS? Ready for use in production?
Thanks
You can definitely use it in production, it is deployed internally at Google and we have a bunch of users. It doesn’t currently work on MacOS, but one of my colleagues is currently working on a port to Mac.
I like it. Recently, I realized that I’m looking for tools that are doing one thing well. It looks like such tool and I will give it a try
The project is awesome. I like the terminal session tool that can help to improve my job. Thank you for your sharing.
Will this one not try to be a window manager?
Not trying to be a window manager is pretty much the reason it exists!
What were the core workflows at google you guys were looking to replace ?
We live in a GUI world and you’re on a terminal, how much space does Tmux take up exactly?
80x24
I meant ram and overall hardware resources since it claims to be lightweight.
Oh. :P
Will use it for sure. starred it.
screen is lightwight tmux alternative
No mention of screen?
I'm too old.
Screen is discussed along with tmux in the [comparison section](https://github.com/shell-pool/shpool#tmux-and-gnu-screen) of the README. For most of the section I just say `tmux` because saying `tmux` or `screen` can get annoying and they have a very similar set of features.
I betrayed screen over a decade ago and switch to tmux, and have been immensely happy. I have a tremendous amount of love and appreciation for the venerable Screen, but realistically very few people use it anymore. I don't think it makes much sense to compare. For the few that do still use Screen, they pretty much know how it compares to tmux so the tmux compare is pretty applicable.
I'm a happy screen user. But tbh, the main benefit (to me) is default ctrl-a key binding, while tmux would require a config (which I actually think is great, that tmux politely doesn't conflict by default).
Not sure why I'd want to switch.
Not sure why I'd want to switch.
Ability to run `tmux <command>` in the terminal and have it affect the current tmux session was a huge feature for me. The other was actually being able to understand and write my config file. You can get somewhat far in Screen without writing any config, but I wanted some small tweaks to optimize my workflow. For example, a more vim-style way to navigate windows, easier splitting of panes, the new prompt on a pane split to be the current working directory of the pane I was on when I triggered the split, easy ability to swap the location of panes, etc. It's not prettified at all since I'm the only (intended) user, but my tmux.conf if it's helpful to anyone: https://gist.github.com/FreedomBen/9c52a6fa1543689798a8a42b6...
It doesn't actually require a config. You can set the binding on the command-line when you launch it. Anything you can represent in a config file with Tmux (set -g prefix C-o) can be expressed on the command-line.
Furthermore, in my opinion, both the defaults (C-a, C-b) are bad, as they conflict with default readline key bindings for cursor movement.
Furthermore, in my opinion, both the defaults (C-a, C-b) are bad, as they conflict with default readline key bindings for cursor movement.
It is mentioned in the first paragraph of the README:
shpool is a service that enables session persistence by allowing the creation of named shell sessions owned by shpool so that the session is not lost if the connection drops. shpool can be thought of as a lighter weight alternative to tmux or GNU screen.
shpool is a service that enables session persistence by allowing the creation of named shell sessions owned by shpool so that the session is not lost if the connection drops. shpool can be thought of as a lighter weight alternative to tmux or GNU screen.
I mean, nobody mention Screen here, in comments, when I wrote my comment
A lightweight tmux alternative? Tmux is already an incredibly lightweight C program in terms of binary size and resource usage.
I assumed they meant “lightweight” in the sense that tmux can take quite a bit of setup and practice to get comfortable in, when using for the very first time.
I love tmux but it’s definitely not “n00b” friendly.
I love tmux but it’s definitely not “n00b” friendly.
$ tmux
# run your command in it
# Ctrl+b D to detatch
later, to attach back to it
$ tmux a -t 0
That probably covers 50% of usage. The rest would be naming the sessions, splitting the window panes. Anything else?
# run your command in it
# Ctrl+b D to detatch
later, to attach back to it
$ tmux a -t 0
That probably covers 50% of usage. The rest would be naming the sessions, splitting the window panes. Anything else?
Yes.
Window management, mouse support, key bindings (I really dislike the defaults for a few of them), selection/copy/paste, macros etc
All stuff that doesn’t need to be configured but if you look at any tmux tutorial you’ll see boat loads of details about. Which can be confusing because how do you know if you don’t need to know it?
Also what’s the basics for one person isn’t going to be the basics for another. Eg I rarely use the detach capabilities these days whereas the panes and windows are something I do use lots.
My point is this: tmux is sufficiently complicated that a complete beginner might not know what features they need to learn.
Window management, mouse support, key bindings (I really dislike the defaults for a few of them), selection/copy/paste, macros etc
All stuff that doesn’t need to be configured but if you look at any tmux tutorial you’ll see boat loads of details about. Which can be confusing because how do you know if you don’t need to know it?
Also what’s the basics for one person isn’t going to be the basics for another. Eg I rarely use the detach capabilities these days whereas the panes and windows are something I do use lots.
My point is this: tmux is sufficiently complicated that a complete beginner might not know what features they need to learn.
[deleted]
tmux takes over scrollback, so it's not possible to scroll the buffer in the same way as without tmux. This tool seems to solve the problem more elegantly.
https://github.com/whalesalad/dotfiles/blob/master/tmux.conf...
Scrolling works pretty well for me.
Scrolling works pretty well for me.
That gets you scrolling, yes, but not in the same way as without tmux.
Without tmux, your terminal emulator uses its scroll-back buffer to render as you scroll, not requiring any intermediate copies of the lines of text scrolling into view.
With tmux, your terminal emulator no longer handles that, and instead tmux must pass a copy of each line freshly scrolled into view to the terminal emulator, which involves an intermediate copy of that text and re-triggers the terminal emulator’s parsing (as far as your terminal emulator is concerned, it has never seen this line of text yet). All of that (and some other subtle overhead I’m not mentioning here) are completely avoided outside of tmux (or more specifically: whenever the terminal emulator is free to manage its own scroll-back).
Without tmux, your terminal emulator uses its scroll-back buffer to render as you scroll, not requiring any intermediate copies of the lines of text scrolling into view.
With tmux, your terminal emulator no longer handles that, and instead tmux must pass a copy of each line freshly scrolled into view to the terminal emulator, which involves an intermediate copy of that text and re-triggers the terminal emulator’s parsing (as far as your terminal emulator is concerned, it has never seen this line of text yet). All of that (and some other subtle overhead I’m not mentioning here) are completely avoided outside of tmux (or more specifically: whenever the terminal emulator is free to manage its own scroll-back).
tmux does support scrolling and copy-paste, but they often work subtly differently than the way they do in a native terminal. For example, when I try putting `set -g mouse on` in `~/.tmux.conf`, scrolling mostly works fine but if I scroll up and then start typing or press up, I won't jump right to the bottom of the session the way I'm used to in native Alacritty (which I will often do as a way to return after scrolling back through a bunch of print output). This isn't a huge deal, and you can definitely get used to it, but it can be frustrating if you like how your normal terminal emulator works and don't want it to change.
nothing in life is free, what do you honestly expect?
This is kind of a strange comment to leave to the author of the tool that's being compared...
Obviously "nothing in life is free" - the person you're replying to literally spent a bunch of time writing a solution to their problem.
"what do you expect?" - the person literally wrote what they expected after having written the code to do exactly that. OP has been all over this thread being incredibly diplomatic in both explaining why they wrote a replacement for (part of) tmux, and constantly following it up with "but by all means if that doesn't sound right to you, use tmux it's a great tool".
It feels a lot like "well, if you don't like it go do it yourself", which is deeply ironic.
Obviously "nothing in life is free" - the person you're replying to literally spent a bunch of time writing a solution to their problem.
"what do you expect?" - the person literally wrote what they expected after having written the code to do exactly that. OP has been all over this thread being incredibly diplomatic in both explaining why they wrote a replacement for (part of) tmux, and constantly following it up with "but by all means if that doesn't sound right to you, use tmux it's a great tool".
It feels a lot like "well, if you don't like it go do it yourself", which is deeply ironic.
[deleted]
Yeah that's a good point, "lightweight" was probably not the best term. I meant lightweight in terms of the cognitive overhead of picking up a new tool, not really in terms of performance. I would expect that shpool will perform better on some workloads and tmux will perform better on others (though in both cases they are probably good enough).
The main difference is that tmux is a power user tool that you generally invest in configuring and tweaking to get just right, while shpool is meant to be set up quickly to solve the specific problem of dropped connections and then mostly forgotten about.
The main difference is that tmux is a power user tool that you generally invest in configuring and tweaking to get just right, while shpool is meant to be set up quickly to solve the specific problem of dropped connections and then mostly forgotten about.
Interesting thanks. I interpreted "lightweight" to mean available features. i.e. just the persistent connection, none of the other bloat[1].
[1]: to be clear, I don't mean "bloat" in a negative way. I'm a long time tmux user and I love it, absolutely love it, and won't be giving it up anytime soon. I don't personally think it has any bloat. But, I use the features. If one only wanted persistent connections, then all of tmux is quite a bit of bloat. It's all perspective.
[1]: to be clear, I don't mean "bloat" in a negative way. I'm a long time tmux user and I love it, absolutely love it, and won't be giving it up anytime soon. I don't personally think it has any bloat. But, I use the features. If one only wanted persistent connections, then all of tmux is quite a bit of bloat. It's all perspective.
Does this mean you don't plan on taking any ideas from screen/tmux and implementing them in your tool?
Well potentially some, but definitely not tiling and screen splitting.
lightweight in terms of features of course.
it simply allows you to have multiple shell/term sessions on a server and be able to switch between them from any terminal. Kind of a 'flat ctrl-Z' cum 'nohup' if you will.
No windows, splits, etc, no client software at all in fact.
it simply allows you to have multiple shell/term sessions on a server and be able to switch between them from any terminal. Kind of a 'flat ctrl-Z' cum 'nohup' if you will.
No windows, splits, etc, no client software at all in fact.
Oh thanks for checking, then I'll leave this. Splits are my primary feature in tmux.
[deleted]
[deleted]
I super duper highly recommend iterm2 (macos) + its integrated tmux support. It was relatively popular in my circles at google when I was there.
It comes with this tool’s benefit of native scrolling/cp paste PLUS the huge benefit of “right click to split vertical/horizontal”.
It comes with this tool’s benefit of native scrolling/cp paste PLUS the huge benefit of “right click to split vertical/horizontal”.
Don't overlook the awesome "automatically bury session" option, which hides the "actual" iTerm2 window running the tmux control plane: https://iterm2.com/documentation-buried-sessions.html and this is the preference I mean: https://github.com/gnachman/iTerm2/blob/v3.5.2/Interfaces/Pr...
I also have dedicated .ssh/config entries for ensuring that ssh connects directly to tmux:
I also have dedicated .ssh/config entries for ensuring that ssh connects directly to tmux:
Host whatever-mux
Hostname whatever
RequestTTY yes
RemoteCommand /usr/bin/tmux -u -CC attThe `tmux -CC` is pretty dope. I’m still surprised that not more terminals have picked it up yet.
Most GUI features (new tab, new split, scroll, search, copy/paste, etc.) just work, and it all syncs with `tmux`.
Be aware though that it can be a bit buggy if you have a fancy `tmux.conf`, and that if you rely on any `tmux` plugins then most of those simply won’t work.
Most GUI features (new tab, new split, scroll, search, copy/paste, etc.) just work, and it all syncs with `tmux`.
Be aware though that it can be a bit buggy if you have a fancy `tmux.conf`, and that if you rely on any `tmux` plugins then most of those simply won’t work.
I'm especially surprised that tmux itself can't be used as a client of a remote control mode session.
It is pretty annoying that the only terminal that I know of that supports tmux control mode only works on mac.
It is pretty annoying that the only terminal that I know of that supports tmux control mode only works on mac.
What benefit would you get if tmux itself became a control mode client?
You'd get pretty much same experience, with textual splits, modeful keyboard shortcuts to access scrollback & copy/paste etc. — which I'm not saying is bad but tmux already does that. Well, I suppose over ssh it'd allow you to access remote tmux session(s) from a local tmux, so maybe allowing little more flexibility mixing panes from multiple remote hosts(?) But still pretty much similar.
The whole point of control protocol was to allow native [G]UI where each pane feels like a native standalone terminal, no?
You'd get pretty much same experience, with textual splits, modeful keyboard shortcuts to access scrollback & copy/paste etc. — which I'm not saying is bad but tmux already does that. Well, I suppose over ssh it'd allow you to access remote tmux session(s) from a local tmux, so maybe allowing little more flexibility mixing panes from multiple remote hosts(?) But still pretty much similar.
The whole point of control protocol was to allow native [G]UI where each pane feels like a native standalone terminal, no?
For use over ssh. It would, ideally, give me:
1. Ability to use local tmux configuration for tmux sessions over ssh. So I don't have to worry about using the default bindings when connecting to a host that doesn't have my tmux config, mouse support is already enabled, etc.
2. Ability to combine and organize remote panes alongside local panes, or panes from other remotes
3. Avoid ending up with nested tmux, where I have a remote tmux session inside of a pane of a local tmux session, which is a pretty terrible experience.
I'd also love it if linux terminals supported it too, but that doesn't seem terribly likely to happen anytime soon.
1. Ability to use local tmux configuration for tmux sessions over ssh. So I don't have to worry about using the default bindings when connecting to a host that doesn't have my tmux config, mouse support is already enabled, etc.
2. Ability to combine and organize remote panes alongside local panes, or panes from other remotes
3. Avoid ending up with nested tmux, where I have a remote tmux session inside of a pane of a local tmux session, which is a pretty terrible experience.
I'd also love it if linux terminals supported it too, but that doesn't seem terribly likely to happen anytime soon.
I looked into this at one point. IIRC it turns out control mode was only added to tmux by the iterm2 dev, for use in his own project. So I guess he didn't care about adding support to tmux itself.
On that front: I've been using wezterm which includes a built-in tmux+mosh functionality, and it works quite well. It gives you first-class scroll/copy/paste management and multi-windows, plus session re-attachment. Probably 50% of my use of my mac is just SSHing in to my Linux box, and wezterm works great for that.
Last I tried there’s 2 major limitations, one is that the version on both ends has to be compatible, another is that it seems the wezterm at the host must be available in the system default PATH. This makes it hard to adapt to arbitrary remote systems that you have limited control of. Tmux+mosh doesn’t have these limitations (well I’m sure the mosh client and server must be compatible to each other but given it is so stable that the last 2 updates are 5 years apart there won’t practically be any problems).
Yes, the versions between client and server do need to be in lock-step. As far as needing to be in the system default path, I haven't run into that: when I initially started using it, I had dropped the executable into ~/bin and that seemed to work (that is in my shell path).
It depends how the rc files are initialized though. I remember last I check I couldn’t get it work on one system (that I don’t have control over those in /etc and those set in my home is not initialized at that stage.)
Mosh implemented a flag to include in the client side: —server=… which solves this problem.
Mosh implemented a flag to include in the client side: —server=… which solves this problem.
The last time I used it, which was probably pushing 5 years ago, it was a big drain on the battery. It was enough that I went back to Terminal.app. Anyone else experience that? Has it improved?
I believe iTerm2 has been GPU accelerated for some years now which probably helps. I’ve only been using it for 3-4 years and haven’t had this issue.
can I still use my keyboard shortcuts for switching between sessions and windows within the session?
I am much happier with that muscle memory than whatever the iterm shortcuts would be.
I am much happier with that muscle memory than whatever the iterm shortcuts would be.
[deleted]
For me tmux is everything.
But I have been looking for 2 utilities they may not exist.
- tty keystroke router: A program that lets you send keystrokes to different tty's (ideally tmux sessions) but not taking over the actual terminal (so sort of a background application , a daemon that listen to a certain key bind and upon pressing it will route all the keypresses to a certain tty/tmux session.
- tty screen real estate extender: Basically be able to link one tty (tmux-window) (attach to it) from two different terminals. These two terminals one of them will be displaying the first N columns second terminal attached will be displaying from N till width of the tty (so you can hook up two monitors and widden your ttys)
- tty keystroke router: A program that lets you send keystrokes to different tty's (ideally tmux sessions) but not taking over the actual terminal (so sort of a background application , a daemon that listen to a certain key bind and upon pressing it will route all the keypresses to a certain tty/tmux session.
- tty screen real estate extender: Basically be able to link one tty (tmux-window) (attach to it) from two different terminals. These two terminals one of them will be displaying the first N columns second terminal attached will be displaying from N till width of the tty (so you can hook up two monitors and widden your ttys)
For the second, <git://git.subdivi.de/~helmut/tcvt.git> might be useful. It's not quite what you asked for; it emulates a two-column virtual terminal within another (virtual) terminal.
If you can extend your terminal window across your two monitors and run `tcvt` within it, that might suit your purposes.
If you can extend your terminal window across your two monitors and run `tcvt` within it, that might suit your purposes.
[deleted]
I'd love to try this, but most of the places that I would want to use it are servers, and the rust requirements are way beyond where debian-stable lives.
Too much hassle to muck with backports and package pinning for a QoL tool - my feedback would be to try to make this install without tomfoolery on the stable branch of major distros.
Too much hassle to muck with backports and package pinning for a QoL tool - my feedback would be to try to make this install without tomfoolery on the stable branch of major distros.
Rust executables generally compile to static binaries. No you don't need to install Rust on the server, just compile once locally and copy the binary.
That is exactly the problem. Debian prefers the dynamic linking approach, where libraries can be updated individually. The problem usually comes down to having all the cargo dependencies packaged inside the debian repo. Which is doable, a similar thing happens for pip and other tools. But still kinda messy
I'm confused why that's a problem. Just because Debian prefers dynamic linking doesn't mean it's incapable of running static binaries.
For most of the rust tools I tried—not this one though—they provided precompiled static binaries that is so easy to deploy to any systems, including ancient distros (like RHEL 7).
So it is easy to solve this problem—just provide pre-compiled binaries on GitHub Releases. I believe the rust ecosystem made this relatively easy.
So it is easy to solve this problem—just provide pre-compiled binaries on GitHub Releases. I believe the rust ecosystem made this relatively easy.
There's a "debian" folder, I suspect it's trivial to build a Deb and manually install?
Seems to have pretty modest install dependencies?
https://github.com/shell-pool/shpool/blob/master/debian/cont...
Seems to have pretty modest install dependencies?
https://github.com/shell-pool/shpool/blob/master/debian/cont...
I had to do this:
git clone https://github.com/shell-pool/shpool.git
cd shpool
sudo apt install libpam0g-dev
# you may need to install build-essential and other packages too as the
# build-depends field in debian/control is incomplete
dpkg-buildpackage -b
sudo apt install ../shpool_0.6.2_amd64.deb
systemctl --user enable shpool
systemctl --user start shpool[deleted]
Recently learned about Zellij and it replaced my tmux usage.
If you don’t mind explaining, what are the advantages you get over tmux?
Main thing that's keeping me right now is copy select with mouse that stays in pane. Tmux would always cross horizontal panes so I'd have to zoom the current pane, alt + mouse select, then unzoom. Zellij I just drag over what I want and release the mouse button. I do however miss using the mouse for pane resizing though.
tmux keeps the selection to the pane for me.
Not something I make use of though, feels faster to copy using the keyboard instead.
Not something I make use of though, feels faster to copy using the keyboard instead.
tmux works out of the box for me.
I tried Zellij and couldn’t get the Alt key to work on mac. And then when ssh’ing into a server I couldn’t see some of the icons because it required a special patched font.
I tried Zellij and couldn’t get the Alt key to work on mac. And then when ssh’ing into a server I couldn’t see some of the icons because it required a special patched font.
There's an entry in the FAQ for alt key on mac: https://zellij.dev/documentation/faq#i-am-a-macos-user-how-c...
Fixed it for me in Alacritty
[deleted]
How could this be a tmux alternative if it only provides session persistence? I use tmux mostly for layout (tiles, multiple windows, etc.) and not for session persistence necessarily. I don't know if this is why other people also use tmux, but I am not sure if "alternative" is the right word here.
I use tmux strictly for persistence only, and WezTerm for layout etc. so this is definitely an alternative for me.
This is very interesting to me as it seems to provide persistence with much less cognitive overhead than tmux or even screen sessions, which are enough that I often don't bother and just use SSH. I also find tmux has a noticable latency overhead (on every terminal I've tried) so I wouldn't use it locally anyway.
Suffice to say this is very interesting and I'll check it out.
This is very interesting to me as it seems to provide persistence with much less cognitive overhead than tmux or even screen sessions, which are enough that I often don't bother and just use SSH. I also find tmux has a noticable latency overhead (on every terminal I've tried) so I wouldn't use it locally anyway.
Suffice to say this is very interesting and I'll check it out.
There are a bunch of minimalist session persistence solutions, including now shpool. If you want layout, there's a minimalist program called `dvtm` that provides those capabilities.
The suggestion usually is to run dvtm inside of dtach/shpool/abduco/diss for layout, and separating the concerns that way.
The suggestion usually is to run dvtm inside of dtach/shpool/abduco/diss for layout, and separating the concerns that way.
It's definitely not a complete alternative, but a surprising number of tmux users are only in it for the session persistence. We did a little internal (criminally underpowered and confounded) survey of some tmux users at google and found that half of them were only really using it for session persistence. I was really surprised by this and thought more people would be using all the slick tiling features that tmux has.
I think there is a whole group of vim + tmux people out there and their primary use case may not be session persistence, but to construct an IDE like environment, which is also my use case.
Note that vim also has windows, tabs and tiling, along with terminals.
Yeah I was expecting a lot of that, which is why I found that survey data so surprising.
It could be a tmux alternative if the session persistence is the only feature of tmux you care about, and you don't like the rest of it.
I use it the same way because I use it locally 100% of the time. I would probably care about persistence more if I used tmux on remote machines.
[deleted]
"The main way that shpool differs from tmux is that tmux is a terminal multiplexer which necessarily means that it offers session persistence features, while shpool only aims to be a session persistence tool. In contrast to tmux the philosophy of shpool is that managing different terminals is the job of your display or window manager, not your session persistence tool."
What if the computer user does not use a window manager. Many years ago I stopped using X11 and started using textmode only. Then tmux was released and appeared in NetBSD packages collection, it soon went into NetBSD base and I have been using it with almost zero problems ever since. If I am forced to run a graphics layer so that I can run a window manager so that I can run shpool, then is this solution truly "lightweight". The shpool program might be lightweight but the system I would need to run it would be heavyweight, when compared with textmode, no graphics.
For me, an assessment of "lightweight" also needs to consider the compile-time requirements. For example, I use a static copy of GCC that weighs in at 242.3 MiB and I can obtain libevent and libtinfo, the only two third-party tmux dependencies, from any number of mirrors across the internet. I like that GCC does not try to connect to the internet by default, or otherwise. When I lose an internet connection, I use the time to compile programs. GCC, and probably most if not all C compilers, add no friction to doing that.
What if the computer user does not use a window manager. Many years ago I stopped using X11 and started using textmode only. Then tmux was released and appeared in NetBSD packages collection, it soon went into NetBSD base and I have been using it with almost zero problems ever since. If I am forced to run a graphics layer so that I can run a window manager so that I can run shpool, then is this solution truly "lightweight". The shpool program might be lightweight but the system I would need to run it would be heavyweight, when compared with textmode, no graphics.
For me, an assessment of "lightweight" also needs to consider the compile-time requirements. For example, I use a static copy of GCC that weighs in at 242.3 MiB and I can obtain libevent and libtinfo, the only two third-party tmux dependencies, from any number of mirrors across the internet. I like that GCC does not try to connect to the internet by default, or otherwise. When I lose an internet connection, I use the time to compile programs. GCC, and probably most if not all C compilers, add no friction to doing that.
"Scrollback and copy-paste will work exactly as they do in your native terminal, while they can behave differently when using tmux."
I use tmux for session management, including but not limited to windowing, on each single host. I generally work _outside_ tmux, using send-keys to interact with each window. I have daemons running in their own windows.
There is no graphics layer, no window manager and no terminal emulator. I stay in textmode.
I make heavy use of tmux features like send-keys and buffers. I use buffers, namely load-buffer, paste-buffer and save-buffer, as "copy-paste".
I do not use a mouse. I "select text" using UNIX utilities, not cursor movement.
The tmux scrollback buffer is not an issue because I work outside of tmux. For daemons running in tmux windows, I use multilog and tai64nlocal for logging.
The copy-paste issue is a non-issue because the "native terminal" for me is textmode and textmode, unlike a terminal emulator, has no copy-paste.
This tmux setup is lighter weight than running 1. a graphics layer, 2. a window manager, 3. a terminal emulator and 4. shpool.
I use tmux for session management, including but not limited to windowing, on each single host. I generally work _outside_ tmux, using send-keys to interact with each window. I have daemons running in their own windows.
There is no graphics layer, no window manager and no terminal emulator. I stay in textmode.
I make heavy use of tmux features like send-keys and buffers. I use buffers, namely load-buffer, paste-buffer and save-buffer, as "copy-paste".
I do not use a mouse. I "select text" using UNIX utilities, not cursor movement.
The tmux scrollback buffer is not an issue because I work outside of tmux. For daemons running in tmux windows, I use multilog and tai64nlocal for logging.
The copy-paste issue is a non-issue because the "native terminal" for me is textmode and textmode, unlike a terminal emulator, has no copy-paste.
This tmux setup is lighter weight than running 1. a graphics layer, 2. a window manager, 3. a terminal emulator and 4. shpool.
Then you can run tmux locally for the multiple windows and then in each window use this if you need to connect remotely to resumable sessions there.
On the other hand if your use case is just windowing on a single host (local only or remote only) then probably stick with tmux.
On the other hand if your use case is just windowing on a single host (local only or remote only) then probably stick with tmux.
[deleted]
I used to use tmux, but then switched completely jupyter terminals.
my browser is my terminal now, and I can easily upload/download files via browser (dont type SCP anymore) with a mouse click, open terminal windows, open Python notebook and do stuff.
life has never been easier after I completely switched to jupyter notebooks+terminals
plus, because it is browser based, I can roam from multiple devices.
my browser is my terminal now, and I can easily upload/download files via browser (dont type SCP anymore) with a mouse click, open terminal windows, open Python notebook and do stuff.
life has never been easier after I completely switched to jupyter notebooks+terminals
plus, because it is browser based, I can roam from multiple devices.
Doesn't the notebook store outputs locally? Wouldn't it get out of sync when changing device?
Also cells can be out of order and overwritten and such. Seems like a questionable fit.
Also cells can be out of order and overwritten and such. Seems like a questionable fit.
I use remote notebook and just connect to it.
The key to out of order problem is simple: once a piece of code works - save it in .py module and import it. Very little discipline is required to achieve significant productivity gain.
That way notebook is always clean and tidy and always resembles a “pseudo code”, with implementation detail hidden in modules (that were tested and are working).
The key to out of order problem is simple: once a piece of code works - save it in .py module and import it. Very little discipline is required to achieve significant productivity gain.
That way notebook is always clean and tidy and always resembles a “pseudo code”, with implementation detail hidden in modules (that were tested and are working).
You were talking about replacing the terminal with notebooks, I assumed you meant for terminal tasks.
If you are using notebooks for notebook coding tasks then fine but what does that have to do with tmux?
If you are using notebooks for notebook coding tasks then fine but what does that have to do with tmux?
There are two ways to run shell commands:
1. Jupyter has terminals feature in addition to notebook (New->Terminal instead of New->Notebook). You can run any number of terminal sessions, they will be persisten like tmix and each open in separate browser window.
They are also shareable and easy to collab, so you can toss the terminal URL to your colleague to let him continue where you left off, or let him monitor stdout as you run some long running process.
2. You can run shell command and capture its output in python var inside jupyter cell with “!” macro, for example:
This is more readable and maintainable than bash oneliners and magic with awk and more powerful
Things like read cav, json, write parquet, any manipulation with data, both local and remote is a breeze and I dont feel like constrained by bash syntax.
Most importantly code is readable and maintainable
1. Jupyter has terminals feature in addition to notebook (New->Terminal instead of New->Notebook). You can run any number of terminal sessions, they will be persisten like tmix and each open in separate browser window.
They are also shareable and easy to collab, so you can toss the terminal URL to your colleague to let him continue where you left off, or let him monitor stdout as you run some long running process.
2. You can run shell command and capture its output in python var inside jupyter cell with “!” macro, for example:
files = !ls *.csv
files = !ls *.csv
pd.concat([pd.read_csv(x) for x in files]).MyColname.value_counts().to_frame().to_csv(“summary.csv”)
This is more readable and maintainable than bash oneliners and magic with awk and more powerful
Things like read cav, json, write parquet, any manipulation with data, both local and remote is a breeze and I dont feel like constrained by bash syntax.
Most importantly code is readable and maintainable
I see, you're using the JupyterLab Terminal as a terminal, I misread. Apologies.
[deleted]
see also: byobu
https://www.byobu.org/
https://www.byobu.org/