Re: Reliably sending binary codes to TRAMP processes

[Michael Albinus]

JD Smith <jdtsmith@gmail.com> writes:

Hi,

> In developing an application that uses APC codes (like
> "\x1b_...\x1b/") to communicate with an external process, I noticed
> that when I try this with remote processes, TRAMP does not faithfully
> pass binary sequences on to the process.  I tracked it down to the use
> of the flags "-t -t" in the ssh call (the backend I am using).

Not so easy to change in general. The "-t -t" for ssh/scp direct async
connections was added by intention, due to bug#71050 and bug#71259.

> I was
> able to lift that restriction with:
>
>   (setf (alist-get 'tramp-direct-async (alist-get "ssh" tramp-methods nil nil 
> #'equal)) '(("")))
>
> But this feels rather hackish.

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?

> Is there a recommended way to request that TRAMP do no translation of
> binary data sent to a processes it starts, for all of its various
> connections methods?  This is a normal PTY process, not a pipe, and I
> use direct async.

Not in general. But I'll extend the Tramp manual by describing the
tramp-direct-async change in (info "(tramp) Improving performance of
asynchronous remote processes"), like

--8<---------------cut here---------------start------------->8---
   *Note*: For the ‘ssh’ and ‘scp’ methods, TRAMP does not faithfully
pass binary sequences on to the process.  You can change this by
changing the respective connection argument (*note Predefined
connection information::) via

     (add-to-list 'tramp-connection-properties (list "/ssh:" "direct-async" t))
--8<---------------cut here---------------end--------------->8---

> Thanks,
>
> JD

Best regards, Michael.