unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Ergus <spacibba@aol.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Issue with remote async processes.
Date: Mon, 28 Mar 2022 18:47:29 +0200	[thread overview]
Message-ID: <20220328164729.ksbpk6j3urc76b35@Ergus> (raw)
In-Reply-To: <87lewufngz.fsf@gmx.de>

On Mon, Mar 28, 2022 at 11:14:20AM +0200, Michael Albinus wrote:
>Ergus <spacibba@aol.com> writes:
>
>Hi,
>
>> 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
>process-file.
>
>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
>instead.
>
>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,
Ergus



  reply	other threads:[~2022-03-28 16:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220324222414.6k5cj2ovxfnpozwr.ref@Ergus>
2022-03-24 22:24 ` Issue with remote async processes Ergus
2022-03-25  8:55   ` Michael Albinus
2022-03-26 19:48     ` Ergus
2022-03-27  7:22       ` Michael Albinus
2022-03-27 20:46         ` Ergus
2022-03-28  9:14           ` Michael Albinus
2022-03-28 16:47             ` Ergus [this message]
2022-03-29  8:55               ` Michael Albinus
2022-03-29 11:46                 ` Ergus
2022-03-29 17:45                   ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220328164729.ksbpk6j3urc76b35@Ergus \
    --to=spacibba@aol.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).