[mikenew]

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]

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]

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]

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

[Geezus_42]

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.

[Jtsummers]

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.

[CoolCold]

we do use multiconnections when doing interviews - candidate solving test case on VM, interviewers are observing. Idea was not to confuse candidates by requiring screensharing during the interview, just see the particular ssh session.

[mkhnews]

Hi. Nice kit. > I couldn't use my normal `i3`/`sway` bindings to switch between terminals inside a tmux session Just curious, what are your normal 'i3'/'sway' bindings that you cannot get to work with tmux ? And what actual terminal program do you use ? Perhaps tmux wants more config than most people care to bother with, but scrollback and copy-paste can be configured just as you like.

[ethanpailes]

If you’re using a tiling window manager your window switch keybindings necessarily conflict between the manager and tmux, since if you configure the same one and then press it while focused on a tmux window, the tiling window manager will override tmux and claim the event.

Scrollback and copy paste cannot always be configured as you want. I’ve shared some specifics elsewhere in this thread.

[mkhnews]

Hi. ok, I get that. Maybe something like A-left to move to next i3 window and A-S-left to move to next tmux window within an i3 window ? Perhaps a tiling window manager with multiple windows combined with tmux dividing some of those windows further into sub-windows isn't an ideal flow.

[qi437103]

It's not i3/tmux, but a similar problem exists for vim/tmux, where the vim window management keys will conflict with tmux's.

And there's https://github.com/numToStr/Navigator.nvim that unifies the keys by letting the outside layer (tmux) always ask the inside layer (vim) before any movements.

Although that is indeed a lot more setup. But works pretty well.

[sandreas]

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

1: https://zellij.dev/

[DEADMINCE]

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.

[eliaspro]

The most fullscreen it can do:

- CTRL-p, f (regular fullscreen)

- CTRL-p, z (zoom/remove borders)

[DEADMINCE]

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

[cookiengineer]

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

[ceving]

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.

[cookiengineer]

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?

[ceving]

I am just saying that opening an unpredictable amount of ports is a problem for every firewall admin.

[KolenCh]

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

[cookiengineer]

Sorry, mobile typo. Been using it since around 2013.

[clepto]

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.