Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: Logging run-time warnings from an embedded perl interpreter

by gamache (Friar)
on Nov 19, 2007 at 17:51 UTC ( [id://651710] : note . print w/replies, xml ) Need Help??


in reply to [RESOLVED*] Logging run-time warnings from an embedded perl interpreter

I dare not use strict or warnings, because there appears to be a lot going on behind the scenes and I have no clue how it may affect things.

warnings and strict are very useful for precisely this situation; they will let you know if weird shit is happening behind the scenes. There also exists use diagnostics; for even more verbosity. I strongly recommend you enable warnings and strict checking, and see if something pops out at you.

In general, if warnings and/or strict break things, things were already broken to begin with.

Replies are listed 'Best First'.
Re^2: Logging run-time warnings from an embedded perl interpreter
by Hercynium (Hermit) on Nov 19, 2007 at 18:34 UTC
    I just put strict and warnings into my code and now I remember why I don't do that with this software :)

    When a user-specified block of code is evaluated, some variables are already created in it's scope. If you use those variables in your code and then enable strict and warnings the application won't save your code to run later.

    I side-stepped the warnings with the ever-so-icky my $pre_set_var if 0; construct (which I learned about here just a few weeks ago!)

    Anyhow, I've enabled strict and warnings and even diagnostics, but I've still no clue how to get the stuff those spit out on STDERR into a log file for an embedded interpreter!

      I haven't had to do that, but maybe the following works for you?

      BEGIN { close STDERR; my $logfile = '/some/hardcoded/path/where/to_put_your.log'; open STDERR, ">", $logfile or die "Couldn't create logfile: $!"; };

      Put that code somewhere where it gets run as early as possible (for user code) - maybe you can even specify modules to be loaded when you start the program?

        Thanks for the code snippet. I just put that code into a 'reboot handler' (something custom I built that *should* have been part of the app in the first place) and sure enough I'm getting all sorts of fun stuff in my log file...
      As far as I know "use strict" and "use warnings" use warn/die to "spit" out messages. I have use "$SIG{__WARN__}" and "$SIG{__DIE__}" to catch/log them.
        Thanks - I've never worked with trapping signals before, but I'll try now and report back what I can get out of it.
      That sounds as though it might be the problem?

      If you've got variable name clashes with the app itself, then there's a reasonable chance you're hurting its internals.

      Unless such names are documented ways of interacting with the app, it seems like poor design. I would have thought they could have scoped the names into packages and had a limited/no lexical scope over your code.

      The my $x if 0; construct is a bad (and unreliable in that's its behaviour may change in different versions of perl) way of generating what C programmers know as a static variable, i.e. one which maintains it's value across invocations of the function. This may not be what you're expecting, I don't know.

        actually, it's just there so that the application can 'see' those vars when validating the code, before storing it for later execution.

        What appears to be happening with this app is that a persistent perl interpreter is running, and then user-defined 'snippets' of code are evaluated within that interpreter when an SNMP event happens. There are certain variables made available to the user for use within those code snippets, created and set at run-time somehow by the app. However, when you turn on strict within the snippet, using those vars results in a validation error. Hence my use of the (admittedly icky) construct.

        For data that I wish to persist between code evaluations I've been using our %VAR = () unless %VAR; which works as expected, though it still feels icky. The app gives no ready mechanism for initialization of anything at startup, and my experiments with BEGIN blocks have been less than encouraging.

        Anyhow, I appreciate the advice! Perhaps someday I'll find the time to develop an app that can compete with this monstrosity and force the developers to actually make it usable for a change :)