Show HN: Shpool, a Lightweight Tmux Alternative

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.

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.

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.

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.

Lightweight in terms of speed. Tmux makes even the slowest terminal feel like a Ferrari.

People say the use the likes of alacritty for the speed, and then they run tmux and make it slower than even gnome-terminal.

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.

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

I think you would love zellij[1]. Go check it out, it is awesome.

1: https://zellij.dev/

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.

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.

The `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.

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?

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:

  Host whatever-mux
    Hostname whatever
    RequestTTY yes
    RemoteCommand /usr/bin/tmux -u -CC att

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.

Does nohup allow attaching back to the session? That seems to be the primary use case of shpool.

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/

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...

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

If you don’t mind explaining, what are the advantages you get over tmux?

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.

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.

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

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.

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.

| /dev/null ?

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

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 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.

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?

For me, mosh and tmux are like socks and shoes.

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.

"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.

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.

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.

You might prefer Eternal Terminal as a TCP mosh alternative:

https://eternalterminal.dev/

80x24

Oh, thanks for catching this. I'll clean it up https://github.com/shell-pool/shpool/pull/43

If he was an OpenBSD fan he might have been overly anti-Linux.

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.

Not trying to be a window manager is pretty much the reason it exists!

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/screen is a way of life.