* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively [not found] <m1tu8789mt.fsf.ref@yahoo.es> @ 2022-06-26 20:14 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-06-26 20:47 ` Lars Ingebrigtsen 0 siblings, 1 reply; 7+ messages in thread From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-26 20:14 UTC (permalink / raw) To: 56239 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-26 20:14 ` 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 @ 2022-06-26 20:47 ` Lars Ingebrigtsen 2022-06-27 10:28 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Lars Ingebrigtsen @ 2022-06-26 20:47 UTC (permalink / raw) To: 56239; +Cc: Daniel Martín 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-26 20:47 ` Lars Ingebrigtsen @ 2022-06-27 10:28 ` Michael Albinus 2022-06-27 10:41 ` Lars Ingebrigtsen 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2022-06-27 10:28 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 56239, Daniel Martín 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-27 10:28 ` Michael Albinus @ 2022-06-27 10:41 ` Lars Ingebrigtsen 2022-06-27 11:24 ` Eli Zaretskii 0 siblings, 1 reply; 7+ messages in thread From: Lars Ingebrigtsen @ 2022-06-27 10:41 UTC (permalink / raw) To: Michael Albinus; +Cc: 56239, Daniel Martín 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-27 10:41 ` Lars Ingebrigtsen @ 2022-06-27 11:24 ` Eli Zaretskii 2022-06-27 11:49 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Eli Zaretskii @ 2022-06-27 11:24 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: michael.albinus, 56239, mardani29 > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-27 11:24 ` Eli Zaretskii @ 2022-06-27 11:49 ` Michael Albinus 2022-06-29 13:34 ` Michael Albinus 0 siblings, 1 reply; 7+ messages in thread From: Michael Albinus @ 2022-06-27 11:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 56239, mardani29 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#56239: 28.1; Cannot send signals by name to inferior process by calling signal-process interactively 2022-06-27 11:49 ` Michael Albinus @ 2022-06-29 13:34 ` Michael Albinus 0 siblings, 0 replies; 7+ messages in thread From: Michael Albinus @ 2022-06-29 13:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 56239, mardani29 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-06-29 13:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <m1tu8789mt.fsf.ref@yahoo.es>
2022-06-26 20:14 ` 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
2022-06-26 20:47 ` Lars Ingebrigtsen
2022-06-27 10:28 ` Michael Albinus
2022-06-27 10:41 ` Lars Ingebrigtsen
2022-06-27 11:24 ` Eli Zaretskii
2022-06-27 11:49 ` Michael Albinus
2022-06-29 13:34 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).