Live data from Hacker News

Show HN: Shpool, a Lightweight Tmux Alternative

github.com

81–90 of 201 posts

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#81
post #70
post #49

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.

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

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

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#82
post #72

Earlier quoted context omitted.

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!

lol!

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#83
post #71
post #65

Earlier quoted context omitted.

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.

Did you have to use a particular setting? I looked into it a few times but couldn't figure it out.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#84
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?

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#85
post #77
post #46

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 alwa…

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…

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

Re: Show HN: Shpool, a Lightweight Tmux Alternative

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

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#87

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.

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.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#88
post #22

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 j…

> 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

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

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#89
post #83
post #71

Earlier quoted context omitted.

tmux keeps the selection to the pane for me. Not something I make use of though, feels faster to copy using the keyboard instead.

Did you have to use a particular setting? I looked into it a few times but couldn't figure it out.

Tried it in a container with only "set -g mouse on" in the config and it works fine (v. 3.2a).

My best guess is that your terminal selection is overriding tmux.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#90

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/

Post reply on HN