Re: Reliably sending binary codes to TRAMP processes

[Michael Albinus]

JD Smith <jdtsmith@gmail.com> writes:

Hi JD,

[Please keep tramp-devel@gnu.org in Cc, for the archives.]

> and then, when creating the process:
>
>     (with-current-buffer buf
>      (setq default-directory dir)
>      (let ((tramp-connection-properties
>     (cons (list nil "direct-async" t) tramp-connection-properties)))
>        (with-connection-local-application-variables 'ipy
>          (apply #'make-comint-in-buffer proc-name buf (file-local-name
>     interpreter) nil
>         (and ipy-interpreter-args
>      (split-string-and-unquote ipy-interpreter-args)))))
>      (ipy-mode))

I'm not sure whether it works completely as expected. Likely, the
connection property "direct-async" is cached, so it will be used for all
direct async processes, not only for your own. That's why I've done the
voodoo with with-tramp-saved-connection-property and
tramp-set-connection-property.

> I'm hopeful the `nil' criteria I used here will be fine, since as I
> understand most TRAMP connections to remote processes use SSH for the
> process communication anyway, independent of how they treat files.

This could be another source of annoyance for users, who use different
Tramp methods in parallel. My voodoo has tried to avoid this.

> I also patched the interrupt to be simpler and avoid SSH getting
> killed by `internal-default-interrupt-process':
>
>     (tramp-send-command
>          vec (format "kill -2 %d 2>%s" pid
>     (tramp-get-remote-null-device vec))
>          'never-open 'no-output)
>
> always returning `t'.  I put this function (locally) at the front of
> `interrupt-process-functions`.   If I understand correctly, control
> master is automatically enabled by TRAMP if possible, so
> `tramp-send-command' should be quite fast, as it re-uses the existing
> SSH connection.

Sounds proper.

> BTW, the only way C-c chars ("\003") get translated
> into SIGINT is if there is some TTY somewhere along the chain (either
> with "-t -t" or via an explicit remote shell), which is not the case
> for pure direct-async.

Yes, this is still a dark area for me.

> My simple idea of asking the remote process to self-report its PID and
> updating the process property also works fine:
>
>     (process-put proc 'remote-pid pid)
>
> I'll look for a good spot to contribute an update to the manual along
> these lines soon.

Yep. I'll appreciate it much.

> BTW, this note about rsync in the manual confused me:
>
>      ‘rsync’ performs much better than ‘scp’ when transferring files
>      that exist on both hosts.  However, this advantage is lost if the
>      file exists only on one side of the connection.
>
> Presumably that's true only for the first transfer, after which the
> file _will_ exist on both hosts?  I.e. further transfer do gain this
> advantage.

Oops, this must be decades old text. I've fixed it in my local repo:

--8<---------------cut here---------------start------------->8---
     ‘rsync’ performs much better than ‘scp’ when transferring files
     that exist on both hosts.  However, this advantage is lost if the
     file exists only on one side of the connection, during the first
     file transfer.
--8<---------------cut here---------------end--------------->8---

> Best,
> JD

Best regards, Michael.