Remote Pseudoterminals

[onionisafruit]

> 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]

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.

[layer8]

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

[DHowett]

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.

[marcosdumay]

Userspace terminals look like a very good solution to a large set of problems that really should not exist, but do nonetheless.

[blueflow]

Whats wrong with the pty-forwarding approach used by SSH?

[zokier]

jupyter?

[throwoutway]

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?

[trav4225]

FYI, somewhat related:

https://mosh.org/