4 ms·
Remote Pseudoterminals
- onionisafruit 4y ago> 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.
- marcosdumay 4y agoI 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.
- layer8 4y ago> 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.
- zokier 4y agojupyter?
- blueflow 4y agoWhats wrong with the pty-forwarding approach used by SSH?
- layer8 4y agoApparently the fact that it doesn’t work on AWS, per the TFA.
- marcosdumay 4y agoUserspace terminals look like a very good solution to a large set of problems that really should not exist, but do nonetheless.
- DHowett 4y agoThis 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.
- trav4225 4y agoFYI, somewhat related: https://mosh.org/ https://mosh.org/
- throwoutway 4y agoI 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?