in reply to Strange SIGNAL HANDLER behavior...

The problem you're running into is that you're actually invoking your signal handler when you're setting it up. The line   local $SIG{QUIT} = \&GotSignal('quit'); is creating a reference to the result of invoking GotSignal, and assign the reference to $SIG{QUIT}. Not what you intended, but Perl is just following orders.

One alternative to your second, working code fragment is   local $SIG{QUIT} = sub { GotSignal('quit') };

Replies are listed 'Best First'.
Re: Re: Strange SIGNAL HANDLER behavior...
by Clownburner (Monk) on Oct 24, 2001 at 23:41 UTC
    That makes perfect sense, and is kinda what I was thinking.. But: 1) why do the Camel, Llama, and Goat all show examples like this, then? Perl Cookbook, pg 587: 
    $SIG{INT} = \&got_int;

    [download]
    ..and 2) Why doesn't the hard anonymous subroutine reference also execute the subroutine immediately? Doesn't this say set $SIG{QUIT} to the value returned by sub{ GotSignal('quit'} }; ?? 
      local $SIG{QUIT} = sub { GotSignal('quit') };

    [download]
    I'm just trying to make sense of Perl's internal logic here.. Maybe that's my first mistake... ;-)
    "Non sequitur. Your facts are un-coordinated." - Nomad
[reply]
[d/l]
[select]

      The difference is that you have parens following the sub name, which parses as a subroutine call. You can't create a reference to a sub invocation with particular arguments, you can only create a reference to a sub. If you need to set values in the sub, you'll need closures.

[reply]

In Section Seekers of Perl Wisdom