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

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!	[reply] [d/l]
Re^3: Logging run-time warnings from an embedded perl interpreter by Corion (Patriarch) on Nov 19, 2007 at 19:19 UTC
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: $!"; };` [download] 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?	[reply] [d/l]
Re^4: Logging run-time warnings from an embedded perl interpreter by Hercynium (Hermit) on Nov 19, 2007 at 20:16 UTC
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...	[reply]
Re^3: Logging run-time warnings from an embedded perl interpreter by Anonymous Monk on Nov 19, 2007 at 18:46 UTC
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.	[reply]
Re^4: Logging run-time warnings from an embedded perl interpreter by Hercynium (Hermit) on Nov 19, 2007 at 19:21 UTC
Thanks - I've never worked with trapping signals before, but I'll try now and report back what I can get out of it.	[reply]
Re^3: Logging run-time warnings from an embedded perl interpreter by jbert (Priest) on Nov 20, 2007 at 08:58 UTC
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.	[reply] [d/l]
Re^4: Logging run-time warnings from an embedded perl interpreter by Hercynium (Hermit) on Nov 25, 2007 at 15:50 UTC
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 :)	[reply] [d/l]