Hm. You shouldn't need to do this. Unless you're using package variables in a persistant environment (like mod_perl)--which you shouldn't be doing.

There is a rarely used built-in reset.

But really, you shouldn't need to be doing this. If you post your script and describe your runtime environment more fully, you would probably get a better solution to your problem.

Find and solve the root problem.   Don’t patch mere symptoms.

If the script “is run on many other servers without this problem,” then the root problem, which you must find and understand, is:   “what is making this server environment different?”

Problems like these are bellwethers.   They reveal the existence of a problem, doing so in an easily visible way.   If you “merely mask” them, the problem does not go away.   It only becomes vastly more difficult to spot, and the application remains unstable.   As you continue to thrash away at it, as you will, client confidence erodes.

sundialsvc4:

This is another one of those nodes where I wish I could click the ++ button a few more times. It's easily the best response to the OP that I've read so far.

...roboticus

What about those cases were you can't change the root of the problem? I've worked in shops where getting approval for something like XML::Simple is a three-year process. What do you do in the mean time while your changes to the web server are waiting to be approved?

Initialize all your variables whenever they need it; don't assume the system will do it for you.

As we all very well know, “software configuration management” (that onerous approvals-process) really is a critical thing.   We cannot edge around it, and we really do not want to.   Nor should we have to.   If there is a defect in the code, then it is probably in the code:   in the code that your team has written; not in what made it to CPAN.   (Which code also made it through Test::Harness as a precondition to being successfully installed on your computer in the first place.)

“Root causes” are typically architectural, and as such they are often very expensive to fix.   They are like foundation problems on a house ... or worse.   But I also think that one of the worst “root causes” arise from the change process itself.   Someone finds a bug and, with or without documenting the change, “makes it go away.”   Trouble is, the problem only “goes away” symptomatically.   The underlying issue often remains ... concealed, un-addressed, and now even more thoroughly wrapped up in obfuscation than it ever was before.

Hence, you really have no choice but to dig down and find out why this thing is breaking.   Consider yourself very lucky, in fact, that the “incorrect value” that you are dealing with happens to be undef.   Perl knows how to die when a variable contains this particular value.   It won’t say a word, though, if a “2” is really supposed to be a “3,” even though this would merely be yet-another manifestation of exactly the same underlying problem...

Best advice?   Learn as much as you can about automated software testing, i.e. Test::Harness and all of its kin.   The stuff that you see CPAN doing, every single time you install or update something.   All of the source-code for how CPAN does this is right there.   The tools are well-developed and very refined.   Even if you begin only by creating test-suites for your most simple and foundational code, you will be amazed (as I certainly was) at what it turns up.   It is seriously like having the waters of the lake upon which you are confidently traveling ... getting ready for another release ... suddenly turned clear, and all around you, directly in front of you, are thousands of obstacles, land-mines, sharks, what-have-you ... every one waiting to be “discovered” and in the very worst possible way.   You obviously cannot finish this kind of thing, “ex post facto,” but you can surely start, and any-and-all progress that you make in this direction will be a massive step in the right direction.

Then you put it in writing that the work-around will be fragile, may make other bugs harder to find and fix, and will lead to much greater expense in the future and perhaps more serious bugs.

It seems to keep variable values from one call of the Perl script to the next one. (the webpage produced by Perl creates a form, which calls back on the script). This script is run on many other servers without this problem.

It seems more likely that the problem has to do with CGI parameters rather than with other variables in the script. You may want to study the the CGI man page -- esp. the section on "Creating Fill-Out Forms", where the 2nd paragraph gives a note about default values for form variables. It may be worthwhile to create a simple test CGI script that can demonstrate the problem, including the server-dependent behavior, so that you can work out an appropriate solution, and then factor it into the larger application.

As sundialsvc4 said above, it makes more sense to figure out how this one server differs from others. You may need to fix your script (rather than fixing the server), but the point is to make sure the fix is based on a proper understanding of the problem.

One more thing, about the concept of "initializing all variables" in a perl script "in one fell swoop". In a well-written script, such a concept makes no sense. At any given moment of run-time (e.g. at the transition from BEGIN to MAIN), many variables in the script are effectively non-existent, because they are lexically scoped to specific, minimal blocks of code that aren't being executed at this moment; you can't initialize something that doesn't exist yet (or doesn't exist anymore).

my $return_main = ''; 
foreach my $key (keys %main::) {
    $return_main .= "$key = $main::{$key}\n";
}
print $return_main;
[download]

my $return_env = '';
foreach my $key (keys %ENV) {
    $return_env .= "$key = $ENV{$key}\n";
}
print $return_env;
[download]

I think you're being unreasonably insistent. Perl makes certain guarantees re initialization and I don't see a problem with relying on that. To my eye, explicit initialization often clutters more than it clarifies. For example, I prefer:

my $fred;    # $fred contains undef
my @jock;    # @jock is empty
[download]

to the explicitly initialized:

my $fred = undef;
my @jock = ();
[download]

Similarly, ANSI C guarantees that global/static variables are initialized to zero and I often take advantage of that by omitting explicit initialization, especially when initializing arrays (as I did, for example, in Re: Rosetta PGA-TRAM).

I sure this will never happen to you or your code but what would happen if someone pass the code through a automate code translator ... say Perl 5 to Perl 6 or Fortran77 ... god knows. What would happen then? You don't know do you. It all depends on what the translator does, doesn't it? Or how the other language wants to initialize things. Since you did not implicitly initial your variables. I hope you remain blissfully unaware.