bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> > Unfortunately, it's not such simple. signal-process can also deliver a
>> > signal to a process running on a remote host. The signal names on that
>> > host might differ from the signal names on the local host, collected by
>> > Fsignal_names.
>> >
>> > How do we want to handle this? I don't see a simple solution, because
>> > the file name handler machinery is not in use here.
>>
>> I think users will just have to use numbers in those cases (which is
>> still possible).  I.e., the symbol names are a convenience where it
>> works, but if not, then users can't use those.
>
> I agree, but there's a larger problem here: signal numbers that
> correspond to given names are also system-dependent.  That is, SIGINT
> could be 2 on one system and 295 on another.  So if you type
>
>   M-x signal-process RET INT RET
>
> you could send to the process a signal number that will be interpreted
> on the remote host as some completely different signal.
>
> So I think we should at least document that symbolic names should be
> used for remote processes only very carefully, if at all.

I don't mean to refrain from signal names. We have them already - Tramp
determines those names on the remote host when
process-file-return-signal-string is non-nil. The signal names are
returned when process-file returns with a retcode greater or equal 128.

I like to use this existing mechanism also with signal-process. The
point is that signal-process (and interrupt-process) don't use the file
name handler mechanism, but an own implementation based on variables
signal-process-functions and interrupt-process-functions. This I would
like to move to the default file name handler implementation, which
would include a solution for signal names.

Best regards, Michael.