[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue with remote async processes.

From: Ergus
Subject: Re: Issue with remote async processes.
Date: Mon, 28 Mar 2022 18:47:29 +0200

On Mon, Mar 28, 2022 at 11:14:20AM +0200, Michael Albinus wrote:
Ergus <> writes:


What's reason process-file doesn't support to use a buffer for stderr?

Performance? Technical?

History. process-file and start-process are derived from call-process
and start-file-process.

call-process allows only (REAL-BUFFER STDERR-FILE), and so does

start-process allows only BUFFER in its docstring (no separation between
stdout and stderr). So start-file-process did originally. Later, when
I've reimplemented it in Tramp using make-process, I wanted to support
the separate stderr buffer of make-process, and I have extended it,
therefore. However, this is not reflected in the docstring, and you
might be better served to follow the official API, and use make-process

Best regards, Michael.

Again very thanks...

So far I have complains with the emacs process API, there are many
function sometimes redundant and with confusing similar names, some of
them are only available for one specific case (like process-lines*,
which is available as a wrapper of call-process but not for the
process-file case considering if there is a find-file-name-handler)...

I would actually expect a simpler function interface with two extra
parameters (remote async).

The async may unify make-process and call-process families
The remote may unify process-file with call-process families

That may reduce the 4 functions to a single one...

I use Tramp extensively and I have observed that several packages are
broken with tramp just because of that... the developers use one of them
without been aware of the others...

Any way...

An extra comment:

(process-command process) always returns `/bin/sh -i` when the process
was executed remotely. I understand the reasons, but I am not sure if
this is intended... I mean, I am interested in the real executed command
when it failed for example. (either the complete one or the one passed
to start-file-process)

Is there a way to retrieve the full command like when the process
executed locally??

Sorry to bother so sooooo much, but documentation is sometimes not very
clear about these sort of details...

Again, thanks in advance,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]