[HN Gopher] Show HN: Shpool, a Lightweight Tmux Alternative
___________________________________________________________________
Show HN: Shpool, a Lightweight Tmux Alternative
shpool is a terminal session persistence tool developed internally
at google to support remote workflows, which we have open sourced.
Author : ethanpailes
Score : 218 points
Date : 2024-06-13 13:22 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jauntywundrkind wrote:
| 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.
| andrewla wrote:
| 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 wrote:
| 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 wrote:
| > 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
| Tyr42 wrote:
| But tmux on server survives the laptop sleeping. That's the
| key value.
| chrisweekly wrote:
| "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 wrote:
| Unbundling tmux is a great concept!
|
| Other tools that can overlap in use case are EternalTerminal and
| mosh which provide sessions that survive disconnects.
| ethanpailes wrote:
| 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?
| remram wrote:
| 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.
| randomtoast wrote:
| A lightweight tmux alternative? Tmux is already an incredibly
| lightweight C program in terms of binary size and resource usage.
| ethanpailes wrote:
| 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.
| freedomben wrote:
| 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 wrote:
| Does this mean you don't plan on taking any ideas from
| screen/tmux and implementing them in your tool?
| jacknews wrote:
| 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 wrote:
| Oh thanks for checking, then I'll leave this. Splits are my
| primary feature in tmux.
| hnlmorg wrote:
| 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 wrote:
| $ 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?
| Tyr42 wrote:
| Scrolling.
|
| That's a key feature when you don't reflexively use less
| and ] isn't a natural keybind for "let me scroll please".
| pawelduda wrote:
| Also search, copy-paste
| hnlmorg wrote:
| 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.
| CyberShadow wrote:
| 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.
| whalesalad wrote:
| https://github.com/whalesalad/dotfiles/blob/master/tmux.conf.
| ..
|
| Scrolling works pretty well for me.
| ethanpailes wrote:
| 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.
| whalesalad wrote:
| nothing in life is free, what do you honestly expect?
| bobthecowboy wrote:
| 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.
| cstrahan wrote:
| 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).
| bjoli wrote:
| 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 wrote:
| How about calling it "fast" then?
| blacklion wrote:
| No mention of screen? I'm too old.
| ethanpailes wrote:
| 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 wrote:
| 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.
| blacklion wrote:
| I mean, nobody mention Screen here, in comments, when I wrote
| my comment
| freedomben wrote:
| 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.
| e12e wrote:
| 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.
| spudlyo wrote:
| 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.
| freedomben wrote:
| 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...
| KingOfCoders wrote:
| Recently learned about Zellij and it replaced my tmux usage.
| aranelsurion wrote:
| If you don't mind explaining, what are the advantages you get
| over tmux?
| xhrpost wrote:
| 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.
| tjoff wrote:
| tmux keeps the selection to the pane for me.
|
| Not something I make use of though, feels faster to copy
| using the keyboard instead.
| xhrpost wrote:
| Did you have to use a particular setting? I looked into
| it a few times but couldn't figure it out.
| tjoff wrote:
| 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.
| ibrarmalik wrote:
| 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 wrote:
| 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
| pnutjam wrote:
| Why is this better then the old school "screen"?
| pnutjam wrote:
| 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 wrote:
| 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
| michaelmior wrote:
| I'm not following what the difference is between installing
| screen on the server and installing shpool in the server.
| beryilma wrote:
| 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 wrote:
| 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.
| andrewla wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ethanpailes wrote:
| 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.
| beryilma wrote:
| 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.
| eigenvalue wrote:
| nohup is also useful for this situation, but a lot of people
| don't seem to know about it!
| tasuki wrote:
| Does nohup allow attaching back to the session? That seems to
| be the primary use case of shpool.
| eigenvalue wrote:
| 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.
| chaps wrote:
| Or use GDB to change stdin/stdout of the nohup'd process to
| the current shell!
| krupan wrote:
| lol!
| bandie91 wrote:
| like reptyr[1] or retty[2] does?
|
| [1] https://github.com/nelhage/reptyr [2]
| https://github.com/lkundrak/retty
| threePointFive wrote:
| 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.
| rangerelf wrote:
| 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.
| zbentley wrote:
| 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 wrote:
| 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 wrote:
| 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?
| setopt wrote:
| 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.
| setopt wrote:
| 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.
| thayne wrote:
| 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.
| mtlmtlmtlmtl wrote:
| 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.
| linsomniac wrote:
| 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.
| mdaniel wrote:
| 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
| mikenew wrote:
| 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 wrote:
| 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.
| ethanpailes wrote:
| 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 :).
| bee_rider wrote:
| 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).
| Jtsummers wrote:
| 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.
| Geezus_42 wrote:
| 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.
| sandreas wrote:
| I think you would love zellij[1]. Go check it out, it is
| awesome.
|
| 1: https://zellij.dev/
| DEADMINCE wrote:
| 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 wrote:
| 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.
| cookiengineer wrote:
| 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 decades, probably, and it is pretty
| awesome for latent mobile connections (read as: throttled 2G
| @16kBit/s with interruptions).
|
| https://github.com/mobile-shell/mosh
| nrh wrote:
| 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.
| michaelmior wrote:
| 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.
| e12e wrote:
| 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 wrote:
| 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
| berkes wrote:
| And the most demanding part of that listing can be done on
| a build machine.
|
| This benefit of compiled languages is often overlooked by
| folks who are (mostly/only) familiar with dynamic languages
| like PHP, Python or Js/Ts
| Scarbutt wrote:
| 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.
| praveen4463 wrote:
| Will use it for sure. starred it.
| tasuki wrote:
| 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 wrote:
| I always found tmux and screen clunky to use when all I wanted
| was the persistence so this project is right up my alley.
| chaps wrote:
| This is more of a `screen` replacement than a `tmux` replacement,
| yeah? Was hopeful for an actual replacement (no, not iterm) to
| tmux.
| e12e wrote:
| 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?
| chaps wrote:
| 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.
| remram wrote:
| Both of them are both of those things.
| Phrodo_00 wrote:
| 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.
| wnoise wrote:
| It has allowed that for a long, long time.
| jamal-kumar wrote:
| 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?
| DEADMINCE wrote:
| If he was an OpenBSD fan he might have been overly anti-Linux.
| radarsat1 wrote:
| 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 wrote:
| | /dev/null ?
| slt2021 wrote:
| 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.
| remram wrote:
| 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.
| slt2021 wrote:
| 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).
| remram wrote:
| 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?
| slt2021 wrote:
| 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: files = !ls *.csv
|
| This allows you to mix&match and interleave bash and
| python and store intermediate data in variables, instead
| of pipes files = !ls *.csv
| pd.concat([pd.read_csv(x) for x in files]).MyColname.valu
| e_counts().to_frame().to_csv("summary.csv")
|
| Just one sample I just used today: This code merge all
| csv files (and will correctly merge even if column names
| are random order in diff files), and group by one field
| and save stats.
|
| 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
| mdaniel wrote:
| 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_
| ethanpailes wrote:
| Oh, thanks for catching this. I'll clean it up
| https://github.com/shell-pool/shpool/pull/43
| nazgu1 wrote:
| 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 wrote:
| 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 wrote:
| You might prefer Eternal Terminal as a TCP mosh alternative:
|
| https://eternalterminal.dev/
| freddieventura wrote:
| 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)
| wnoise wrote:
| https://man.freebsd.org/cgi/man.cgi?query=dtach
| feel-ix-343 wrote:
| Will this one not try to be a window manager?
| tambourine_man wrote:
| 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
___________________________________________________________________
(page generated 2024-06-13 23:00 UTC)