Python Forum
a feature i'd like to see added to ssh
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
a feature i'd like to see added to ssh
#1
a feature i'd like to add, or have added, or see added, to ssh is an exchange (added protocol layer) between a program run at the remote host and the client making the connection, offers an API to incrementally access a file, or multiple files, at the remote host, along with an action request sent by the remote host.   a special program on the remote host would be given a list of files on the remote host to edit.  it would then send special controls to trigger an editor in the client.  the local edit run by the client would request file data to be read for it and pass file data to be written.  in the end the user can do local speed interactive editing of a file on the remote shell.  other file activities could be done this way as well.  the change to ssh could be minimal.  added code would watch for the trigger and run a child program on the local host to do the rest an just shuffle data between the remote host and the child until the child exits.  after it exits, go back to normal operation.  everything else would be implemented in these external programs which could be implemented in Python.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#2
Simple RPC ( remote procedure call )  program can wait for a "trigger". It's relatively easy with this. There is a Python module called zerorpc which is just for that. Based on pyzmq. I am not sure if editing a remote file, if it's not a small one, is a good idea. What happens if the connection is lost during editing the file? Excluding this, it could be done within a tmux session with running vim or nano. Even the connection is lost you can atach to the session again later and continue with the editing
"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."
https://freedns.afraid.org
Reply
#3
if the connection is lost then the program on the remote end won't get a "final save" operation and the original file will be unchanged while the transient file with the incremental changes up to the lost connection can be saved like many editors do (emacs saves this as '#{filename}#').  on the local client side it should save the file locally if it did not get a proper response to "final save" before either a timeout or connection loss.  this design should also look on the local host for file recovery.

i don't know how RPC can work over the existing SSH connection (which may be relayed over things like Tor so making a separate connection is not an option).
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#4
You can establish an ssh tunnel and use that for just about everything.
"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."
https://freedns.afraid.org
Reply
#5
yes, but if that kind of tunneling is used, the remote edit program needs to find the port.  so, maybe a "standard" port that the remote program "to edit a remote file locally" will connect to, to start the editing.  then we still need a good way to switch the user interaction over to the editor.  mixed output is generally not a problem; two or more processes outputting all get their output to go to the terminal.  the difficulty is the input; the edit program has to get ssh to suspend reading while the editing is going on.  shells run other programs OK by not doing any reading until the program exits.  another way is to have the local side program to be the program that runs ssh and passes all the terminal input to ssh, then do the local side editing when a connection comes across from the ssh tunnel.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020