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

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> 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've checked again - we don't send signals to remote hosts
interactively. This would be posible only if the REMOTE argument of
signal-process is non-nil. This doesn't happen interactively. Nothing to
do ATM, therefore.

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

This is a different topic, so we shouldn't discuss it here.

Best regards, Michael.