Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Shpool, a Lightweight Tmux Alternative

github.com

Post reply on HN
Print view View original

181–190 of 201 posts

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#181

Post by lanstin »

remram wrote: post #179
lanstin wrote: post #173

Earlier quoted context omitted.

I always get scared when I accidentally have two shell sessions visible at once in tmux. I immediately exit one. I suppose I should read a bit on it. When I want side to side comparisons I go to the shell running emacs and do it there (post vague because I never remember the different words for windows and panes and shells etc these different apps use.)

tmux has a server containing sessions containing windows containing panes. Screen has sessions, windows, and panes (which it calls regions). I recently finally switched from screen to tmux and I found that it's pretty seamless (especially because I use vi keybinds in tmux still). Some machines at work don't have screen anymore.

Ok,makes sense. Using this terminology, I asked claude and found out how to move a shell from a standalone window to sharing 2 panes with another shell.

Incidentally, this "screen absent" is why you should always volunteer to help create base shells (programmatically via packer not by hand) - emacs and tmux are always there when I made the image.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#182

Post by remram »

lanstin wrote: post #181
remram wrote: post #179

Earlier quoted context omitted.

tmux has a server containing sessions containing windows containing panes. Screen has sessions, windows, and panes (which it calls regions). I recently finally switched from screen to tmux and I found that it's pretty seamless (especially because I use vi keybinds in tmux still). Some machines at work don't have screen anymore.

Ok,makes sense. Using this terminology, I asked claude and found out how to move a shell from a standalone window to sharing 2 panes with another shell. Incidentally, this "screen absent" is why you should always volunteer to help create base shells (programmatically via packer not by hand) - emacs and tmux are always there when I made the image.

What's a base shell?

I don't make the image.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#183

Post by cookiengineer »

ceving wrote: post #162
cookiengineer wrote: post #125

Earlier quoted context omitted.

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

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.

I don't understand your statement, to be honest.

Either you waste lots of traffic bandwidth because you have to have a session identifier or nonce in every packet, or you have to map sessions to ports in order to guarantee persistance when the client drops its connection.

Other ways of doing session handling will lead to an attack surface that can probably be used for DoS attacks.

Maybe I am missing something: How would you solve this, given the limitations of UDP and TCP?

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#184

Post by SeerLite »

frankjr wrote: post #171
cryptonector wrote: post #148

> The biggest advantage of this approach is that `shpool` does not break native scrollback or copy-paste. tmux/screen do not break copy-paste. And that tmux/screen have their own scrollback is a feature. The selling point for shpool is simplicity, which I appreciate. I need terminal multiplexing, but I might use shpool here and there.

> tmux/screen do not break copy-paste Tmux breaks interacting with the clipboard so much that it has its own dedicated Wiki page dealing with all of the different issues and settings: https://github.com/tmux/tmux/wiki/Clipboard

It literally doesn't though. The wiki page is for copying tmux copy-mode's internal selection. The selection and copying mechanisms of the terminal emulator still work just as well.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#187

Post by DEADMINCE »

eliaspro wrote: post #165
DEADMINCE wrote: post #110

Earlier quoted context omitted.

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.

The most fullscreen it can do: - CTRL-p, f (regular fullscreen) - CTRL-p, z (zoom/remove borders)

Thanks I appreciate that! I'll play around with it later today.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#188

Post by loulouxiv »

radarsat1 wrote: post #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.

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.

Re: Show HN: Shpool, a Lightweight Tmux Alternative

#190

Post by efreak »

jamal-kumar wrote: post #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?

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)
Post reply on HN