Remote Pseudoterminals
github.com
Remote Pseudoterminals
1–10 of 11 posts
Re: Remote Pseudoterminals
#2> 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.
Re: Remote Pseudoterminals
#3> 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.
Re: Remote Pseudoterminals
#4> 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…
jupyter?
Re: Remote Pseudoterminals
#5> 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…
Whats wrong with the pty-forwarding approach used by SSH?
Re: Remote Pseudoterminals
#6FYI, somewhat related:
Re: Remote Pseudoterminals
#7I 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?
Re: Remote Pseudoterminals
#8> 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…
Whats wrong with the pty-forwarding approach used by SSH?
Apparently the fact that it doesn’t work on AWS, per the TFA.
Re: Remote Pseudoterminals
#9> 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.
Re: Remote Pseudoterminals
#10> 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…
Userspace terminals look like a very good solution to a large set of problems that really should not exist, but do nonetheless.