Show HN: Shpool, a Lightweight Tmux Alternative

by ethanpailes • 2 years ago

323 184 2 years ago

shpool is a terminal session persistence tool developed internally at google to support remote workflows, which we have open sourced.

jauntywundrkind• 2 years ago

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.

andrewla2• 2 years ago

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.

Retr0id• 2 years ago

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.

zokier• 2 years ago

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

Tyr422• 2 years ago

But tmux on server survives the laptop sleeping. That's the key value.

chrisweekly• 2 years ago

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

gregwebs• 2 years ago

Unbundling tmux is a great concept!

Other tools that can overlap in use case are EternalTerminal and mosh which provide sessions that survive disconnects.

ethanpailes13• 2 years ago

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?

remram7• 2 years ago

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.

dbtc• 2 years ago

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

randomtoast• 2 years ago

A lightweight tmux alternative? Tmux is already an incredibly lightweight C program in terms of binary size and resource usage.

ethanpailes13• 2 years ago

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.

freedomben3• 2 years ago

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.

brisketbbq• 2 years ago

Does this mean you don't plan on taking any ideas from screen/tmux and implementing them in your tool?

jacknews• 2 years ago

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.

wkat4242• 2 years ago

Oh thanks for checking, then I'll leave this. Splits are my primary feature in tmux.

hnlmorg2• 2 years ago

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.

MuffinFlavored• 2 years ago

$ 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?

CyberShadow• 2 years ago

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.

whalesalad2• 2 years ago

https://github.com/whalesalad/dotfiles/blob/master/tmux.conf...

Scrolling works pretty well for me.

bjoli• 2 years ago

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.

kreetx• 2 years ago

How about calling it "fast" then?

blacklion2• 2 years ago

No mention of screen? I'm too old.

ethanpailes13• 2 years ago

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.

jerdfelt• 2 years ago

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.

blacklion2• 2 years ago

I mean, nobody mention Screen here, in comments, when I wrote my comment

freedomben3• 2 years ago

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.

e12e4• 2 years ago

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.

KingOfCoders• 2 years ago

Recently learned about Zellij and it replaced my tmux usage.

aranelsurion• 2 years ago

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

xhrpost2• 2 years ago

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.

ibrarmalik• 2 years ago

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.

decko• 2 years ago

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

pnutjam2• 2 years ago

Why is this better then the old school "screen"?

pnutjam2• 2 years ago

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.

OwseiWT• 2 years ago

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

michaelmior3• 2 years ago

I'm not following what the difference is between installing screen on the server and installing shpool in the server.

beryilma2• 2 years ago

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.

stvltvs• 2 years ago

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.

andrewla2• 2 years ago

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.

barnabee• 2 years ago

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.

sullyj3• 2 years ago

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.

ethanpailes13• 2 years ago

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.

beryilma2• 2 years ago

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.

eigenvalue2• 2 years ago

nohup is also useful for this situation, but a lot of people don’t seem to know about it!

tasuki2• 2 years ago

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

eigenvalue2• 2 years ago

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.

threePointFive• 2 years ago

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.

zbentley• 2 years ago

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/

superfish• 2 years ago

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

ibejoeb• 2 years ago

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?

setopt2• 2 years ago

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.

setopt2• 2 years ago

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.

thayne2• 2 years ago

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.

linsomniac2• 2 years ago

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.

KolenCh5• 2 years ago

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

mdaniel2• 2 years ago

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

ledauphin• 2 years ago

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.

mikenew• 2 years ago

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.

ori_b• 2 years ago

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.

ethanpailes13• 2 years ago

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

sandreas• 2 years ago

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

1: https://zellij.dev/

DEADMINCE3• 2 years ago

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.

clepto• 2 years ago

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.

cookiengineer3• 2 years ago

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

KolenCh5• 2 years ago

I think mosh first appeared in 2012? How can you have been using it for decades?

ceving2• 2 years ago

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.

nrh• 2 years ago

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.

michaelmior3• 2 years ago

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.

augusto-moura• 2 years ago

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

e12e4• 2 years ago

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

krunck• 2 years ago

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

KolenCh5• 2 years ago

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.

Scarbutt• 2 years ago

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.

rkangel2• 2 years ago

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.

praveen4463• 2 years ago

Will use it for sure. starred it.

wetpaws• 2 years ago

see also: byobu

https://www.byobu.org/

tasuki2• 2 years ago

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/

VagabundoP• 2 years ago

I always found tmux and screen clunky to use when all I wanted was the persistence so this project is right up my alley.

cryptonector2• 2 years ago

tmux/screen is a way of life.

chaps7• 2 years ago

This is more of a `screen` replacement than a `tmux` replacement, yeah? Was hopeful for an actual replacement (no, not iterm) to tmux.

e12e4• 2 years ago

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?

chaps7• 2 years ago

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.

jamal-kumar2• 2 years ago

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?

DEADMINCE3• 2 years ago

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

jamal-kumar2• 2 years ago

Nah we're both pretty knowledgable programmers who use both OSes and it was measurably clear

efreak2• 2 years ago

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)

radarsat12• 2 years ago

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.

mctt• 2 years ago

| /dev/null ?

KolenCh5• 2 years ago

I guess they mean they want to be able to look at latest stdout/err without having to write it to a file, but not discarding it all

radarsat12• 2 years ago

How would you tail /dev/null?

loulouxiv• 2 years ago

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.

slt20213• 2 years ago

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.

remram7• 2 years ago

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.

slt20213• 2 years ago

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

mdaniel2• 2 years ago

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

ethanpailes13• 2 years ago

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

nazgu1• 2 years ago

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

rabite• 2 years ago

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.

amethyst• 2 years ago

You might prefer Eternal Terminal as a TCP mosh alternative:

https://eternalterminal.dev/

freddieventura• 2 years ago

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)

_kst_• 2 years ago

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.

wnoise2• 2 years ago

https://man.freebsd.org/cgi/man.cgi?query=dtach

feel-ix-343• 2 years ago

Will this one not try to be a window manager?

ethanpailes13• 2 years ago

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

tambourine_man• 2 years ago

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

ethanpailes13• 2 years ago

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.

1vuio0pswjnm72• 2 years ago

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

lmz• 2 years ago

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.

1vuio0pswjnm72• 2 years ago

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

themk• 2 years ago

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.

ethanpailes13• 2 years ago

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.

cryptonector2• 2 years ago

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.

frankjr• 2 years ago

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

SeerLite• 2 years ago

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.

pipeline_peak2• 2 years ago

We live in a GUI world and you’re on a terminal, how much space does Tmux take up exactly?

johnisgood3• 2 years ago

80x24

pipeline_peak2• 2 years ago

I meant ram and overall hardware resources since it claims to be lightweight.

animegirl2024• 2 years ago

The project is awesome. I like the terminal session tool that can help to improve my job. Thank you for your sharing.

santiagobasulto• 2 years ago

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.

zft• 2 years ago

screen is lightwight tmux alternative

149765• 2 years ago

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/user@1000.service/app.slice/shpool.service
                ├─3895609 /usr/local/bin/shpool daemon
                ├─3895629 -fish
                ├─3895719 systemctl --user status shpool
                └─3895720 pager

alphabetatheta• 2 years ago

What were the core workflows at google you guys were looking to replace ?

johnisgood3• 2 years ago

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

Anything I'm doing wrong?

Show HN: Shpool, a Lightweight Tmux Alternative

Related Stories