sigint

How can I handle SIGINT in Erlang?

倾然丶 夕夏残阳落幕 提交于 2019-11-30 18:03:58
I know how to create custom signal handlers in Java, Python, Ruby, Perl, and Lisp, thanks to Google and a plethora of tutorials. I can't find online how to create handlers for SIGINT, SIGTERM, HUP, etc. in Erlang. You can not. OS signals handled exclusively by Erlang VM. I guess OS signals can be handled in a driver but it can interfere with the VM signal handler so use it on your own risk. I stumbled upon this: http://erlang.org/doc/man/kernel_app.html#erl_signal_server . I have not seen it formally announced anywhere, but I might have missed the announcement. 来源: https://stackoverflow.com

Can I trap signals in R?

≡放荡痞女 提交于 2019-11-30 17:56:54
问题 In bash I can trap SIGINT , SIGKILL , SIGTERM , and so on. That allows me to do different things depending how the program was unexpectedly stopped. Is there a way to do this in R? 回答1: Expanding a bit on my comment which OP asked me to post as an answer The help file for conditions has the description These functions provide a mechanism for handling unusual conditions, including errors and warnings. There are many handling functions explained in the file, with examples. So I suggest starting

Unix signal handling in (common) lisp

流过昼夜 提交于 2019-11-30 13:56:15
问题 I've done a bit of research on this subject and am turning up blanks. There seem to be implementation-dependent ways of doing Unix signal handling in Common Lisp, but is there a package that gives a cross-implementation way of doing signal handling? I would mainly like to listen for SIGINT and do a graceful shutdown in my app. I'm using Clozure CL 1.7 on linux...like mentioned, it would be great for a package for this, but if I have to resort to implementation-specific code, that's fine. I'm

Why is CTRL-C not captured and signal_handler called?

不打扰是莪最后的温柔 提交于 2019-11-30 09:45:56
问题 I have the following standard implementation of capturing Ctrl+C : def signal_handler(signal, frame): status = server.stop() print("[{source}] Server Status: {status}".format(source=__name__.upper(), status=status)) print("Exiting ...") sys.exit(0) signal.signal(signal.SIGINT, signal_handler) On server.start() I am starting a threaded instance of CherryPy. I created the thread thinking that maybe since CherryPy is running, the main thread is not seeing the Ctrl+C . This did not seem to have

Equivalent to “SIGINT” (posix) signal for catching “CTRL+C” under Windows/MinGW

本秂侑毒 提交于 2019-11-30 08:27:14
问题 I am porting a Linux/gcc program under windows and implemented common exceptions handling for both. I was wondering what would be the equivalent of SIGINT signal for MinGW/gcc. Here is how I handle it under Linux : static void handler(int sig) { // Catch exceptions switch(sig) { case SIGABRT: fputs("Caught SIGABRT: usually caused by an abort() or assert()\n", stderr); break; case SIGFPE: fputs("Caught SIGFPE: arithmetic exception, such as divide by zero\n", stderr); break; case SIGILL: fputs(

Readline: Get a new prompt on SIGINT

与世无争的帅哥 提交于 2019-11-30 01:41:01
问题 I've got code similar to the following, using readline: #include <errno.h> #include <error.h> #include <getopt.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <readline/readline.h> #include <readline/history.h> void handle_signals(int signo) { if (signo == SIGINT) { printf("You pressed Ctrl+C\n"); } } int main (int argc, char **argv) { //printf("path is: %s\n", path_string); char * input; char * shell_prompt = "i-shell> "; if (signal(SIGINT, handle

Why is CTRL-C not captured and signal_handler called?

陌路散爱 提交于 2019-11-29 17:01:27
I have the following standard implementation of capturing Ctrl+C : def signal_handler(signal, frame): status = server.stop() print("[{source}] Server Status: {status}".format(source=__name__.upper(), status=status)) print("Exiting ...") sys.exit(0) signal.signal(signal.SIGINT, signal_handler) On server.start() I am starting a threaded instance of CherryPy. I created the thread thinking that maybe since CherryPy is running, the main thread is not seeing the Ctrl+C . This did not seem to have any affect but posting the code as I have it now: __main__ : server.start() server : def start(self): #

catching SIGINT in a multithreaded program

夙愿已清 提交于 2019-11-29 02:22:37
I am writing a multithreaded program where I want to handle a possible Ctrl-C command from the user to terminate execution. As far as I know there is no guarantee that the main thread, which is able to cancel every working thread, will catch the signal. Is it, therefore, necessary to have a different signal handler to the code of the working thread so that anyone will catch the signal if it arrives, or is there another way to do that with having a signal handler only in the main thread's code? You can block signals from the calling thread with pthread_sigmask(). And, as the blocked signals are

Capturing SIGINT using KeyboardInterrupt exception works in terminal, not in script

半世苍凉 提交于 2019-11-28 23:34:10
I'm trying to catch SIGINT (or keyboard interrupt) in Python 2.7 program. This is how my Python test script test looks: #!/usr/bin/python import time try: time.sleep(100) except KeyboardInterrupt: pass except: print "error" Next I have a shell script test.sh : ./test & pid=$! sleep 1 kill -s 2 $pid When I run the script with bash, or sh, or something bash test.sh , the Python process test stays running and is not killable with SIGINT . Whereas when I copy test.sh command and paste it into (bash) terminal, the Python process test shuts down. I cannot get what's going on, which I'd like to

Python: How to prevent subprocesses from receiving CTRL-C / Control-C / SIGINT

独自空忆成欢 提交于 2019-11-28 16:40:09
I am currently working on a wrapper for a dedicated server running in the shell. The wrapper spawns the server process via subprocess and observes and reacts to its output. The dedicated server must be explicitly given a command to shut down gracefully. Thus, CTRL-C must not reach the server process. If I capture the KeyboardInterrupt exception or overwrite the SIGINT-handler in python, the server process still receives the CTRL-C and stops immediately. So my question is: How to prevent subprocesses from receiving CTRL-C / Control-C / SIGINT? robert Somebody in the #python IRC-Channel