emacs-devel
[Top][All Lists]
Advanced

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

Re: Remote process attributes


From: Michael Albinus
Subject: Re: Remote process attributes
Date: Mon, 04 Apr 2022 13:33:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> - list-system-processes and process-attributes shall return process
>>   information of the remote host when default-directory is remote.
>
> Is it really certain that the default-directory being remote is
> evidence significant enough that the user wants to list remote
> processes?  Processes aren't files, and aren't even related to files
> like programs (whose executable files are looked up before we run
> them).

I've checked all occurences of list-system-processes and
process-attributes in core Emacs, GNU ELPA and NonGNU ELPA. This is just
a handful, and all of them could preserve their behavior with the
template I've shown. Really not a big deal.

If both functions are used somewhere else in the future, the
documentation tells what to do. And I could imagine that this
information about remote processes could be used not only in proced.

>> A problem could be to find the proper arguments for ps. I've used a
>> default setting for GNU/Linux, other systems could apply
>> connection-local variables for that. My proof-of-concept implementation
>> offers such settings for the Tramp adb method as well as for remote
>> (Free)BSD systems and ps implementations based on Busybox. That are the
>> test cases I could run locally.
>
> As mentioned in that thread, there are several ps implementations, and
> they differ in what they accept and how they report various
> attributes.  We switched to our own implementation to avoid the
> problems we had using ps.  Now these problems will be back.  I
> envision trouble.

I'm fully aware of this. And for local processes, nothing changes. For
remote processes, my implementation simply returns nil if ps isn't
called with a proper argument list. This could be enhanced case by case,
and users could also configure the ps argument list by themselves, but
for a large fraction of remote systems this would return already useful
information. So it isn't a regression, but rather a progression.

What we could think about is a way to indicate proced whether to return
local or possibly remote process information. I wanted to add a prefix
argument to proced in order to trigger remote process information, but
this is already used for window selection.

Best regards, Michael.



reply via email to

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