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

[Filipp Gunbin]

Hi,

On 28/03/2022 17:40 +0200, Michael Albinus wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
> Hi Filipp,
>
>>> +      (if (tramp-compat-funcall
>>> +           'tramp-send-command-and-check
>>> +           vec (format "\\kill -%s %d" sigcode pid))
>>> +          0 -1))))
>>> +
>>
>> Can the command be a connection-local variable?.  Then the ability to
>> customize, existing before deprecation of proced-signal-function, would
>> not be lost.
>
> Would be possible. However, I fail to understand which command you have
> in mind instead of "kill".

Well, at least kill builtin in shell.  I don't know, I'd just prefer it
be customizable.  This is highly system-dependent, so it'd be more
future-proof.

>>> +  (let ((default-directory
>>> +         (if (and current-prefix-arg (stringp proced-remote-directory))
>>> +             proced-remote-directory temporary-file-directory))
>>> +        failures)
>>
>> As for me, I'd leave the proced-remote-directory thing out.  IIUC, it
>> allows to send signals to remote processes from "normal" proced buffer,
>> with local default-directory (with prefix arg).  I'd be fine with
>> requiring user to open proced from remote directory, with
>> default-directory already "prepared".
>
> What do you do if a user starts proced from a buffer with a remote
> default directory to, let's say, "/ssh:otherhost:/path"?
> proced-send-signal would try to send the signal to otherhost instead of
> your local host.
>
> And no, you cannot prevent this scenario. Users execute proced whenever
> they like.

Yeah, I see, the pid will be taken from localhost, but "kill" will be
sent to remote.  Can we for now just raise an error if we see that the
remote is not simple sudo/su/whatever?  Maybe later we'll be able to
implement "get remote process list".

Filipp