Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re^3: SIG, Modules, and Eval

by ikegami (Pope)
on Aug 16, 2014 at 04:38 UTC ( #1097644=note: print w/replies, xml ) Need Help??

in reply to Re^2: SIG, Modules, and Eval
in thread SIG, Modules, and Eval

$SIG{__DIE__} = sub { return if $^S; ... print(STDERR $_[0]); exit($! || ($? >> 8) || 255); };

Replies are listed 'Best First'.
Re^4: SIG, Modules, and Eval
by kbrannen (Sexton) on Aug 16, 2014 at 19:02 UTC
    I did something similar on one of my first tries to find out what was going on and to fix this. I looked at the call stack and if there wasn't a ".cgi" file in the list then assumed I was in the "compile" stage and just returned. Not as elegent as using $^S but it worked. If I had to do something like this, I like the $^S way better now that I know about it.

    In the end, I'd really like to know why I had to do anything like this. If we have code like:
    package X; BEGIN { whatever; } $main::SIG{__DIE__} = \&some_function; # when does this get run? sub new { ... }
    In what phase is that SIG handler assigned? I would have thought it was in an implied INIT, but the code acts like it's in an implied BEGIN. I ended up solving the entire issue by putting that line in an explicit INIT block, but why did I have to do that?
      $main::SIG{__DIE__} = \&some_function; # when does this get run?

      It gets run at the same time as any other code in the same place would. Give it a try:

      #!/usr/bin/perl use strict; use warnings; use feature qw/say/; sub function { say "Howdy!"; } #die "horribly"; $main::SIG{__DIE__} = \&function; #die "horribly"; #BEGIN { die "horribly"; }

      Try uncommenting each of the various dies; only the one that dies after the signal handler has been assigned will produce a "Howdy!". No implicit blocks of any kind are involved.

      Alternatively, check with -MO=Deparse.

        Right, I should have thought to try a simpler example, so thanks for the prompt. :)

        In essesnce, the code in question run during "BEGIN" time (sort of in an implict BEGIN block) because that's when the "use" is run. I suppose that makes sense, but I've never really thought about that and I've certainly never read about it ... hence my surprose. I can show that with:
        #!/usr/bin/perl # use strict; use warnings; use OurCommon; BEGIN { print "BEGIN in\n"; } CHECK { print "CHECK in\n"; } INIT { print "INIT in\n"; } END { print "END in\n"; } print " main code running\n";
        And with:
        #!/usr/bin/perl # use strict; use warnings; package OurCommon; BEGIN { print "BEGIN in\n"; } CHECK { print "CHECK in\n"; } INIT { print "INIT in\n"; } END { print "END in\n"; } print " non-sub code running\n"; sub new { print "new in OurCommon\n" }
        Running that with a simple "perl" I get:
        BEGIN in non-sub code running
        BEGIN in
        CHECK in
        CHECK in
        INIT in
        INIT in main code running
        END in
        END in
        So as we can see, the "non-sub" code in the module file is run while the "use" is processed, which is during the BEGIN phase. That also makes it clear why putting the code in an INIT block fixed it. I'm more educated now, but I really wished the docs made that more clear. :) Looking in "perldoc perlmod", I can see this info is implied, sort of if I squint real hard, but it's really not obvious to me at all while reading that.

        Thanks to everyone who replied here!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1097644]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2016-09-29 01:07 GMT
Find Nodes?
    Voting Booth?
    Extraterrestrials haven't visited the Earth yet because:

    Results (544 votes). Check out past polls.