Re: Reliably sending binary codes to TRAMP processes

[Michael Albinus]

JD Smith <jdtsmith@gmail.com> writes:

Hi,

> OK thanks, the following combined settings do indeed work to get a
> direct process:
>
> #+begin_src elisp
>     (connection-local-set-profile-variables
>      'remote-direct-async-process
>      '((tramp-direct-async-process . t)))
>
>     (connection-local-set-profiles
>      '(:application tramp :protocol "ssh")
>      'remote-direct-async-process)
>
>     (add-to-list 'tramp-connection-properties
>         (list "/ssh:" "direct-async" t))
> #+end_src
>
> With these in place, I confirm that the process is a direct `ssh -q -e
> none ...' and (importantly) lacks "-t -t", as is needed to send binary
> data correctly.

Thanks for the feedback. I've pushed the proposed extension to the Tramp
manual to the repositories.

> One thing that is unclear to me: do the `connection-local' settings
> have any effect without a matching `connection-properties'?

No. Both is needed.

> Also, why
> is it `tramp-direct-async-process' in one place and just
> "direct-async" in the other?

History. People tend to modify the rather complex structure of
tramp-methods in their config, which is error prone. That's why I have
added the possibility to overwrite tramp-methods arguments by connection
properties.

tramp-methods arguments are alwys symbols, starting with
'tramp-'. Connection properties are always strings, w/o a leading
"tramp-". So this is the result. This mapping is explained in the Tramp manual.

>         BTW, I'd prefer to enable direct-async _only_ for the
>         processes my
>         package creates, not for _all_ SSH processes, leaving that to
>         the
>         user.  
>
>     How do *your* processes differ from user processes? Is there
>     something
>     special in the remote file name, or so?
>
> Do you mean the file name of the remote process executable itself?

No, I mean the "remote" part of a remote file name, like
"/ssh:host". The name of a remote process executable isn't checked.

> Yes, this is distinct and I know it in advance (usually "python[3]" or
> "ipython").  Would the idea be to update the regex in
> `tramp-connection-properties' to target only these executable names?

No. I have no idea yet how to fulfill your request.

Perhaps you can use the macro setq-connection-local in order to wrap
your calls to direct asyn processes, setting connection-local variable
tramp-direct-async-process temporarily only. To be investigated.

> I played around and did some reading.  Very complicated.  From a shell
> terminal I can only test using key bindings like C-c (SIGINT) or C-\
> (SIGQUIT) or C-z (SIGSTOP); from Emacs I can send arbitrary signals
> like `(signal-process (get-buffer-process (current-buffer))
> 'SIGUSR2)'. 
>
> Cases:
>
> 1 Regular SSH from local terminal to a remote shell.  Then start
>   remote process: keyboard-based signals are all propagated to the
>   process.
> 2 ssh -t -t to allocate a remote tty, starting the process directly
>   (within a remote tty): key signals are propagated to the remote tty
>   and translated there into signals for the process (except C-z).
> 3 Ssh without "-t -t" (a la async-remote): there is no remote TTY, so
>   signals via key input are seen by the local ssh and simply close the
>   process.  So C-c simply quits ssh.  This is what I've seen via emacs
>   as well: any signal just closes the process.
> 4 From emacs without any special config (/bin/sh -i showing as the
>   process name): sending SIGUSR2 from emacs *actually works*!  I'm not
>   sure how it is passing a keyless signal over the SSH connection, but
>   I have confirmed that it is.  
>
> I'm afraid my knowledge gets thin here.  I don't understand in general
> how SSH forwards arbitrary signals to remote processes (vs. terminal
> just placing bytes on the SSH input stream which the remote TTY reads
> and translates itself).  But it seems to do so at least in some
> contexts.  Perhaps it has a control channel message for that.  The
> answers here are quite instructive:
>
> apple-touch-icon@2.png 
> Ctrl-C handling in SSH  
> sessionunix.stackexchange.com  
> apple-touch-icon@2.png
>
> It seems there must be some combination of settings that gives binary
> data ✓; signals ✓.

Well, it looks like we must think about rewriting signal handling for
direct async processes. One idea is to send the respective control
character directly. The posting on SX gives useful information, indeed.

Best regards, Michael.