otp
otp copied to clipboard
erlang
otp raw mode with ssh daemon
Hey folks! Not sure if this is the right place to ask/enquire
Been heavily using the raw mode the over the last month for my tui framework.
As part of that, I was exploring exposing the tui over SSH, similar to how the folks at Charm can do with Bubbletea.
I've pretty much got it working but one thing I can't seem to figure out is if it's possible to put the SSH pseudo terminal into raw mode? I have a feeling this isn't really possible, the same raw command I'm for setting it locally doesn't seem to work and I can't really see anything obvious in the ssh docs.
Just wondering if anyone is aware if this should or could work? Would be keen to explore it if it's not supported but feasible! Any insight would be awesome!
Not sure where or who to ask about this generally, so if there's a better place/person, let me know :)
And thanks for the awesome feature! NIFs begone ;)!
Just wanted to add a note that I figured out how to have raw mode style handling by implemented my own ssh_cli on the daemon (nothing fancy required for this to work, seems to just be default behaviour).
It may be nice UX to support the raw mode settings if possible for the built in cli, but maybe this is the expected route/solution.
Please feel free to close this if so, I'll leave it open in the meanwhile to defer to your judgment on that :)!
Thanks!
Sorry for late response.
How much of adjustments you had to make in your own ssh_cli variant to make it work as you wish? Can you share that as gist so I can have look?
We typically have options allowing users to make their customizations. as here with ssh_cli_daemon_option/0. Maybe it is documentation that is missing?
I'm a bit unsure if you succeeded with your framework with already existing option or is it working but is cumbersome and you would like to propose some improvement.
Please, let us know. I'm not aware about anyone asking for something similar but maybe this might be useful if one would like to implement similar library in Erlang ...
Hey! No worries at all :)
Here's the code, it's all in gleam so apologies if it's trickier to read! https://github.com/bgwdotdev/beach/blob/main/src/beach/internal/ssh_cli.gleam
I did indeed go with implementing the ssh_cli custom behaviour as per the docs and by default it acted like raw mode, which was all good, easy to do there, so no real adjustments required outside of implementing all the basic features of it :).
Initially as I remember it, I was trying to just use shell_fun/2 instead which acts more like cooked mode and I was attempting to set that into raw without success. I guess I might suggest this would be the "easy" way if it was possible to have some way to set this to raw, without having to implement ssh_cli yourself, but this is likely a very niche use case (and no doubt I'd have had to go down this route anyway tbh for other technical reasons) ^^;!
It's been a while but I vaguely remembering finding some of code in ssh_shell that was setting the pty terminal mode, not sure if it was overriding my settings or anything, not really sure how this part of things work exactly.
Hopefully that all makes sense, let me know if I can clarify anything :)!
one issue I'm having with the ssh_server_channel behaviour that I can't seem to find docs for is what's happening to any exit/1 messages inside things like terminate/2, they don't seem to report to stdout and not sure if I'm doing something wrong or if supervisor trap_exit or something is doing something with it?
I did see something about things being put to the erlang:logger but that only appeared to out messages from handle_ssh_msg, not the other callbacks. Any advice or extra documentation in this front would help ^^?
@bgwdotdev The thinking about ssh_server_channel behaviour is that create a process that will be hooked into the ssh-application supervisor tree and managed by it supervisor as it is service (request handler) process dependent on other ssh processes. You should therefor not create any links to this process for other processes of yours.
Fair fair, I do believe I'm doing that so I'll look into adjusting, thanks for the recommendation.
Though regardless of that, I was having issues with terminate regardless of linking processes, in the form of having the wrong shape of my data in the state. I didn't realise a fault in init would still send some state back before I had provided any state to return, thus my terminate was essentially silently failing just due to bad args -- a bunch of printf debugging got me there in the end but I felt like I was missing something by not being able to find out how to turn on/report out exit messages. Am I missing a setting somewhere or is that just how it is?
Thanks :)!