ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП |
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы. |
16.15. Installing a Signal HandlerProblemYou want to control how your program responds to signals. You need to do this if you want to catch Ctrl-C, avoid accumulating finished subprocesses, or prevent your process from dying when it writes to a child that has gone away. SolutionUse the $SIG{QUIT} = \&got_sig_quit; # call &got_sig_quit for every SIGQUIT $SIG{PIPE} = 'got_sig_pipe'; # call main::got_sig_pipe for every SIGPIPE $SIG{INT} = sub { $ouch++ }; # increment $ouch for every SIGINT
$SIG{INT} = 'IGNORE'; # ignore the signal INT It also restores handling for that signal to the default: $SIG{STOP} = 'DEFAULT'; # restore default STOP signal handling DiscussionPerl uses the Although a C programmer might think of a signal as SIGINT, Perl uses just INT. Perl figures you only use signal names in functions that deal with signals, so the SIG prefix is redundant. This means that you'll assign to If you want to run your own code when a given signal is received, you have two choices of what to put in the hash: either a code reference or a subroutine name. (This means you can't name a signal handler IGNORE or DEFAULT if you store the string, but they'd be mighty strange names for signal handlers anyway.) If you use a subroutine name that isn't qualified by a package, Perl will interpret this name to be a function in the Perl calls your handler code with a single argument: the name of the signal that triggered it, like Perl defines two special signals, See AlsoThe "Signals" sections in Chapter 6 of Programming Perl and in perlipc (1); your system's sigaction (2), signal (3), and kill (2) manpages (if you have them) |