Re: process-file instead of call-process in proced.el?

[Michael Albinus <michael.albinus@gmx.de>]

Roland Winkler <winkler@gnu.org> writes:

Hi Roland,

>> Thanks for the clarification. So in order to apply the proposal of
>> Fillip, we also need to implement a "remote" version of list-system-processes.
>>
>> `proced' could show then the processes of the remote system, if
>> indicated. For example, if the command is executed with a prefix
>> argument.
>
> To clarify the history of proced: it started out as a front-end for
> ps(1).  That was a mess because there are too many variants of ps(1) out
> in the wild to allow for anything robust.  So Eli kindly wrote the
> built-in functions list-system-processes and process-attributes that
> provide a well-defined base for proced.  These built-in functions are
> not implemented for all platforms and proced does not work for the other
> platforms; that's life.  I believe that again it would be a poor crutch
> if Emacs tried to run ps(1) remotely for a process listing.  Is it
> possible to use a remote instance of emacs to get a process listing on a
> remote machine (and let proced do nothing otherwise)?

I see. So if we don't want to emulate list-system-processes on a remote
host, we need another mean to determine, that a process is killed in a
sudo environment.

The proposal of Filipp (replace call-process by process-file in
proced.el) doesn't fly, because we cannot guarantee, that
default-directory is related to something like a "sudo remote
host". Even worse, it could be anything remote, and we would (try to)
kill a process with a local pid somewhere else ...

Best regards, Michael.