in reply to Problem of scope : $SIG{__WARN__} in a module...

Put the declaration in the module scope? I dunno if you've tried that or not, but that would've been my first thought ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: Problem of scope : $SIG{__WARN__} in a module...

Replies are listed 'Best First'.
Re^2: Problem of scope : $SIG{__WARN__} in a module...
by wazoox (Prior) on Dec 03, 2004 at 18:03 UTC
    Sure I tried it. unfortunately It doesn't work; either I put
    $SIG{__WARN__} = sub { set_dberror(join('',@_))};
    at the beginning of the module and it changes behaviour of all programs using it; I tried too
    local $SIG{__WARN__} = sub { set_dberror(join('',@_))};
    at the beginning of the module, but it just has no effect at all (the dbi errors are happily sput out on STDERR).

      Firstly, you can get DBI to stop spitting errors by:

      $dbh->{PrintError} = 0;

      Secondly, $SIG{__WARN__} doesn't automagically cover anything printed to STDERR, only things that result from a call to warn(), which happens to cause a print to STDERR.

      Finally, if neither of those applies, try:

      our $SIG{__WARN__} = sub { ... }

      For which I'm certain I will be flamed...

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

        Ach, using our didn't come to my mind.
        I'll give it a try just in case...
        PS Why would you be flamed?