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?

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

Thanks - I've never worked with trapping signals before, but I'll try now and report back what I can get out of it.

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 :)