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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56239 in the body.
You can then email your comments to 56239 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; Cannot send signals by name to inferior process by calling
 signal-process interactively
Date: Sun, 26 Jun 2022 22:14:50 +0200

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

Message #8 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 56239 <at> debbugs.gnu.org
Cc: Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#56239: 28.1; Cannot send signals by name to inferior
 process by calling signal-process interactively
Date: Sun, 26 Jun 2022 22:47:30 +0200

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> 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

Message #13 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56239 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#56239: 28.1; Cannot send signals by name to inferior
 process by calling signal-process interactively
Date: Mon, 27 Jun 2022 12:28:57 +0200

Lars Ingebrigtsen <larsi <at> 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.

Message #16 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 56239 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#56239: 28.1; Cannot send signals by name to inferior
 process by calling signal-process interactively
Date: Mon, 27 Jun 2022 12:41:29 +0200

Michael Albinus <michael.albinus <at> 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

Message #19 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: michael.albinus <at> gmx.de, 56239 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#56239: 28.1;
 Cannot send signals by name to inferior process by calling
 signal-process interactively
Date: Mon, 27 Jun 2022 14:24:59 +0300

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

Message #22 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56239 <at> debbugs.gnu.org,
 mardani29 <at> yahoo.es
Subject: Re: bug#56239: 28.1; Cannot send signals by name to inferior
 process by calling signal-process interactively
Date: Mon, 27 Jun 2022 13:49:56 +0200

Eli Zaretskii <eliz <at> 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.

Message #25 received at 56239 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56239 <at> debbugs.gnu.org,
 mardani29 <at> yahoo.es
Subject: Re: bug#56239: 28.1; Cannot send signals by name to inferior
 process by calling signal-process interactively
Date: Wed, 29 Jun 2022 15:34:57 +0200

Michael Albinus <michael.albinus <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.