Here is a working example of something that takes control of %SIG so you can insert other code if you like:

package Sigmund;

use base qw( Tie::Hash );

my $realSig= \%::SIG;

sub TIEHASH {
    return bless {}, shift;
}

sub STORE {
    my( $self, $key, $value )= @_;
    my $prev= $realSig->{$key};
    # Replace this next line with whatever you like:
    warn "Changing $key signal handler.\n";
    $realSig->{$key}= $value;
    return $prev;
}

sub FETCH {
    my( $self, $key )= @_;
    return $realSig->{$key};
}

*::SIG= {};
tie %::SIG, __PACKAGE__;

1;
[download]

I can't guess why you think that your other methods should work. STORE methods do not set values by returning a value nor by overwriting the $key parameter.

Now, if you get anything to work, consider yourself lucky and worry about in what release of Perl it will break. %SIG is magical (yes, that is the real term for it). So when you set values of %SIG, C code inside of Perl gets run in order to set up actual signal handlers. What triggers this C code is called "magic" and you'll have to go read "perldoc perlguts" (and then some) if you want to know more about it.

If I were going to try this, I'd keep a reference to the original %SIG handy and then replace %SIG with my tied hash:

my $realSig= \%::SIG;
*::SIG= {};
tie %::SIG, ...
[download]

(I don't know if the "::"s are of any use in the above code. The "SIG" is special to Perl such that it knows to always find it in package "main", but I'm not certain that this specialness would always be triggered in the above code so I'm trying not to rely upon it.)

Yeah, I realized that the other methods probably wouldn't work (and wasn't suprised when they didn't) but I thought I'd try them anyway (and included them for completeness).

I don't want to run afoul of Perl Magic but I don't see how the method that does work (Ugly Hack) could break in the future. Unless, of course, they change it so that the STORE method is never called (ie, you cannot tie %SIG, period). Can you see any reason why it would?

Personally, it would seem to me that trying to replace %SIG's symbol-table entry would be more likely to break Perl than my method. Thoughts?

In summary, can you see any reason why I shouldn't go ahead with the method that currently works?

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

When you tie a hash, attempts to change the hash no longer change the hash, they call a STORE method instead. So I have no reason to believe that your current method should manage to change the underlying, magical %SIG since it all boils down to $SIG{sig}= $codeRef generating a call to STORE that simply returns, doing nothing. In the case of $SIG{ALRM}, you call this STORE method twice, generating the second call to it from within the first call.

I suspect you have a found a bug in tied variables such that changes to the underlying tied hash leak through when you trigger a second STORE this way (or something similar). This bug probably has other, less desireable effects (like a recent bug where you can't use a different tied variable inside of a STORE method) and so may be fixed and the fix may break your ugly hack.

If you want to be able to change the original %SIG (in order to invoke the magic), then I really think you need to take steps such that you aren't tieing the original %SIG as changing a hash after it is tied isn't supported. You are relying on undocumented behavior.

What I suggested relies on documented behaviors. But it is fringe enough that I don't expect the standard test suites and beta testing would always turn up bugs that happen to break the combined behavior.

        - tye (but my friends call me "Tye")

Buffers Files Tools Edit Search Perl Help                             
+          
#!/usr/bin/perl -w
use strict;
$|++;

{
  package MyTie;

  sub TIEHASH {
    my $class = shift;
    my %value;
    my $self = { value => \%value };
    bless $self, $class;
    warn "blessing $self\n";
    # $self->STORE("ALRM", sub { warn "BONG" });
    $self;
  }

  sub FETCH {
    my $self = shift;
    my $key = shift;

    my $value = $self->{value}->{$key};
    warn "$self is fetching $key as $value\n";
    $value;
  }

  sub STORE {
    my $self = shift;
    my $key = shift;
    my $newvalue = shift;
    warn "$self is storing $newvalue in $key\n";
    $self->{value}->{$key} = $newvalue;
  }
  
  sub DELETE {
    my $self = shift;
    my $key = shift;
    warn "$self is deleting $key\n";
    delete $self->{value}->{$key};
  }
  
  sub CLEAR {
    my $self = shift;
    warn "clearing $self\n";
    %{$self->{value}} = ();
  }
  
  sub EXISTS {
    my $self = shift;
    my $key = shift;
    warn "checking existance of $key in $self\n";
    exists $self->{value}->{$key};
  }

  sub FIRSTKEY {
    my $self = shift;
    warn "calling firstkey on $self\n";
    my $toss = keys %{$self->{value}};
    each %{$self->{value}};
  }

  sub NEXTKEY {
    my $self = shift;
    warn "calling nextkey on $self\n";
    each %{$self->{value}};
  }
  
  sub DESTROY {
    my $self = shift;
    warn "calling destroy on $self\n";
    $self->SUPER::DESTROY;
  }
} 

tie %::SIG, MyTie::;

$SIG{ALRM} = sub { warn "bing!\n" };

alarm(1);
select(undef, undef, undef, 3);
[download]

blessing MyTie=HASH(0x80d9290)
MyTie=HASH(0x80d9290) is storing CODE(0x80d91e8) in ALRM
bing!
calling destroy on MyTie=HASH(0x80d9290)
[download]

Now, uncomment the commented STORE in the early part of the program, and comment out the explicit setting of $SIG{ALRM} at the end, and you get:

blessing MyTie=HASH(0x80d92ec)
MyTie=HASH(0x80d92ec) is storing CODE(0x80d2c30) in ALRM
Alarm clock
[download]

Oh well.

-- Randal L. Schwartz, Perl hacker

$SIG{$key} = sub { print "Simple Method\n"; };
[download]

I've got %SIG tied, so if I try to do that, it will quickly go recursive on my rear-end. I tried it. :-)

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.