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. 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? > 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? Best regards, Michael.
