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

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

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The scenario is a user that wants to send the signal SIGUSR1 (for
example) to an inferior process and does the following:

Switch to the buffer associated with the inferior process.

M-x signal-process RET

Press RET for the process (so that the process associated with the
current buffer is used).

For the signal code, type 'SIGUSR1 (or "SIGUSR1", or SIGUSR1).

The operation fails with the message "Please enter a number".

The docstring of signal-process says that sending a signal by name
should be possible:

"SIGCODE may be an integer, or a symbol whose name is a signal name."

If we call the command non-interactively, it works correctly:

M-: (signal-process nil 'SIGUSR1)

In GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559))
 of 2022-04-04 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.4

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $LANG: en_ES.UTF-8
  locale-coding-system: utf-8-unix

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

[Lars Ingebrigtsen]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> For the signal code, type 'SIGUSR1 (or "SIGUSR1", or SIGUSR1).
>
> The operation fails with the message "Please enter a number".

Yup.  I've now fixed this in Emacs 29.  I wasn't sure whether to allow
completing to USR1 og SIGUSR1, and went with the former, but I don't
really have an opinion on what form to use.  (So feel free to change
that.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> For the signal code, type 'SIGUSR1 (or "SIGUSR1", or SIGUSR1).
>>
>> The operation fails with the message "Please enter a number".
>
> Yup.  I've now fixed this in Emacs 29.  I wasn't sure whether to allow
> completing to USR1 og SIGUSR1, and went with the former, but I don't
> really have an opinion on what form to use.  (So feel free to change
> that.)

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.

Best regards, Michael.

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

[Lars Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> Cc: 56239@debbugs.gnu.org, Daniel Martín <mardani29@yahoo.es>
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Jun 2022 12:41:29 +0200
> 
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
> > 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.

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.

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.