[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.