Remote Pseudoterminals
github.com> Warning: Please do not put this library anywhere near production. It is full of unsafe, unethical, cursed code that occasionally works for inexplicable reasons.
I wish I knew Rust so I could fully appreciate this unethical code.
I didn't look at the code, but I believe it's cursed because of what it does, not because it's unidiomatic Rust.
Terminal handling is a cursed realm. This project is basically all terminal handling, done in a place where no terminal is allowed to exist, and interacting with a badly documented environment that really does not wish it to exist. There are probably some unsafe blocks, but I don't believe the code itself is the extraordinary part.
> I realised half-way through this project that the "right" way to solve this problem would be by building a client-server shell (not SSH, which is not a shell). A shell where all the interactive elements run on the client and the remote server accepts commands over a socket. However I could not find such a shell. I'll leave this as an exercise to the reader.
It would be interesting to split Bash into a front end and back end, with the ability to plug different protocols in between.
This is PowerShell’s remoting model! It supports different transports (SSH, WSMan), keeps interactive elements on the client side, and effects actions on the server side.
Userspace terminals look like a very good solution to a large set of problems that really should not exist, but do nonetheless.
Whats wrong with the pty-forwarding approach used by SSH?
Apparently the fact that it doesn’t work on AWS, per the TFA.
jupyter?
I learned a lot from this post and the solution seems pretty clever. I wonder when it will be “ready for production” from the author’s point of view?
FYI, somewhat related: