> On Jan 28, 2025, at 10:36 AM, Michael Albinus <michael.albi...@gmx.de> wrote:
>
> JD Smith <jdtsm...@gmail.com> writes:
>
> Hi,
>
>> Thanks for your help. I am on TRAMP version: 2.7.2.0.20250101.91903.
>
> That's recent. Later this week I'll release 2.7.2.1 on GNU ELPA, but
> there's no change related to your problem.
>
>> The Tramp manual describes how to change arguments in
>> tramp-methods, see (info "(tramp) Predefined connection
>> information") . In your case, I recommend to add to your init file
>>
>> --8<---------------cut here---------------start------------->8---
>> (add-to-list 'tramp-connection-properties (list "/ssh:"
>> "direct-async" t))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Could you pls confirm that this works for you?
>>
>> Unfortunately this does not work for me. I had formerly used:
>>
>> (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)
>
> This is still relevant. Setting the connection property "direct-async"
> is additional config. And it is activated for a new connection only,
> i.e. you must either start a new Emacs session, or cleanup the recent
> session via tramp-cleanup-connection and friends.
>> The process remains `/bin/sh -i', and binary data do not get
>> sent correctly to the process. Neither does setting
>> `tramp-direct-async-process=t' work. So I'm unsure of which settings
>> to use.
>
> Both: connection-local settings, and connection-properties setting.
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.
One thing that is unclear to me: do the `connection-local' settings have any
effect without a matching `connection-properties'? Also, why is it
`tramp-direct-async-process' in one place and just "direct-async" in the other?
> In case it doesn't work, set tramp-verbose to 6, rerun your test, and
> show the debug buffer. Preferred from an Emacs started with 'emacs -Q'.
>
>> 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? 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?
>> But even with direct-async enabled (with
>> connection-local-set-profiles), I'm confronted with another problem.
>> My application sends binary data (APC commands) AND also sends signals
>> (SIGUSR2) to communicate with the remote process. The situation
>> appears to be as follows:
>>
>> With direct-async-process: binary data ✓; signals ⨉ [1]
>> Without direct-async-process: binary data ⨉; signals ✓ [2]
>>
>> [1] The process is a direct `ssh -q -e` command, binary data is
>> correctly passed, but any signals from Emacs (even C-c C-c) result in
>> the process dying with, e.g.:
>>
>> : C-c C-c
>>
>> Process X exited abnormally with code 255
>>
>> [2] The process is `/bin/sh -i`, binary data get mangled when sent to
>> the process, but signals are correctly propagated and received by the
>> remote process.
>>
>> To summarize, it appears I have quite specific needs here. I'm
>> looking for a combination of settings that:
>>
>> 1 Apply only to the processes my package creates.
>> 2 Allow faithful delivery of binary data to the process (a la
>> direct-async).
>> 3 Allow signals from emacs to correctly reach the remote process (a la
>> a /bin/sh-wrapped remote process).
>>
>> Any ideas to try? Thanks again for your assistance.
>
> Hmm, complex. Have you checked how signals are handled by an ssh session
> started from a shell?
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:
Regular SSH from local terminal to a remote shell. Then start remote process:
keyboard-based signals are all propagated to the process.
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).
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.
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:
https://unix.stackexchange.com/questions/102061/ctrl-c-handling-in-ssh-session
Ctrl-C handling in SSH session
unix.stackexchange.com
It seems there must be some combination of settings that gives binary data ✓;
signals ✓.
