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

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 { ... }

[download]
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?

Replies are listed 'Best First'.
Re^5: SIG, Modules, and Eval
by AppleFritter (Vicar) on Aug 16, 2014 at 19:30 UTC 
    $main::SIG{__DIE__} = \&some_function; # when does this get run?

    [download]

    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"; }

    [download]

    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.

[reply]
[d/l]
[select]
      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
# try.pl

use strict;
use warnings;

use OurCommon;

BEGIN { print "BEGIN in try.pl\n"; }
CHECK { print "CHECK in try.pl\n"; }
INIT { print "INIT in try.pl\n"; }
END { print "END in try.pl\n"; }

print "try.pl main code running\n";

      [download]
      And with: 
      #!/usr/bin/perl
# OurCommon.pm

use strict;
use warnings;

package OurCommon;

BEGIN { print "BEGIN in OurCommon.pm\n"; }
CHECK { print "CHECK in OurCommon.pm\n"; }
INIT { print "INIT in OurCommon.pm\n"; }
END { print "END in OurCommon.pm\n"; }

print "OurCommon.pm non-sub code running\n";

sub new { print "new in OurCommon\n" }

      [download]
      Running that with a simple "perl try.pl" I get: 
      BEGIN in OurCommon.pm
OurCommon.pm non-sub code running
BEGIN in try.pl
CHECK in try.pl
CHECK in OurCommon.pm
INIT in OurCommon.pm
INIT in try.pl
try.pl main code running
END in try.pl
END in OurCommon.pm
      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!
[reply]
[d/l]
[select]

        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

        Well, perlmod says  use Module; is exactly equivalent to   BEGIN { require 'Module.pm'; 'Module'->import; }

        so :)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom