Re: Reliably sending binary codes to TRAMP processes

[Michael Albinus]

JD Smith <jdtsmith@gmail.com> writes:

Hi,

> One way around all this I've found: setup `direct-async' as we
> discussed (full, no "-t -t"), then, upon startup, collect the PID from
> the process itself (e.g., in python: import os; os.getpid()).  Set
> this PID into the process' plist as 'remote-pid.

How do you do this in general? The idea of direct async processes is to
fire the respective command, and forget it. No further handling. It is
intended for speed-up.

And we cannot assume that there is python installed on the remote side,
or that a shell is running (which tells us $$). If you have a proper
patch for Tramp how to retrieve the remote-pid, pls show.

Until we find a way for sending signals to the remote direct async
process, we must point to the non-direct case.

> Good news: this actually works well for signals!  Unfortunately
> `tramp-interrupt-process' causes problems here, due to this unusual
> bit at the end:
>
>     ;; Wait, until the process has disappeared.  If it doesn't,
>     ;; fall back to the default implementation.
>     (while (tramp-accept-process-output proc))
>     (not (process-live-p proc)))))
>
> I must admit I don't understand this code.  If the process remains
> alive after the interruption is sent, the "default implementation" is
> subsequently employed, which, as mentioned above, kills the SSH
> process itself.  Long-lived processes should _not_ necessarily exit
> upon interrupt.  Many of them, e.g. the Python REPL, specifically
> catch SIGINT and use that to interrupt their own running commands.
>
> I wonder if this behavior can be gated behind a custom variable, like
> `tramp-interrupt-ends-process'.  So something like:
>
>     ;; If we expect interrupt to end the process, wait until it
>     ;; has disappeared.  If it doesn't, fall back to the default
>     ;; implementation.
>     (if tramp-interrupt-ends-process
>         (progn (while (tramp-accept-process-output proc))
>                (not (process-live-p proc)))
>       t))))) ; handled

Don't know yet. That will be a longer way to go. But first I must
recover from my recent health malaises.

Best regards, Michael.