Update: I've completely replaced my answer; find the old one in readmore tags below.

Imagine you were a scientist. You research the question whether a new web server caused some changes, or if it was the code organization (or both, or neither of these reasons).

As a scientist, it's your duty to design and run an experiment to decide that question. And since you are a lazy scientist, you chose the simplest experiment that you can think of. Not only does that mean you have less work doing the experiment, but it also means you don't have to write so much when you submit your paper for review.

So, which experiment could you do? A quick brainstorming:

• Run the old code on the new webserver. If it works, the webserver is to blame.
• Run the new code on the old webserver. If it works, the webserver is to blame.
• Dump and inspect the contents of %ENV in the top-level CGI script on the new webserver (not in the module
• Ask on perlmonks

It really depends on your setup if the first two possible experiments are simple, but the third one certainly is.

The fourth has the problem that perlmonks doesn't know your problem too well, and even if they solve the problem for you, you can't submit your paper in the end.

Want to debug your code? Think like a scientist. Start now!

• Are you testing the module and script in the same environment? If you run the script command-line, and run the module under Apache context, %ENV will and should vary.

• Your code may be localizing some values of %ENV. This is actually a good security practice, since it's a potential exploit channel. See perlsec.

One situation in which I can think that %ENV would be different in this case is if %ENV is being modified globally unbeknownst to you. Is it being changed in one of your modules?

Another situation in which %ENV might be different (and in this case not cause side effects) is if you shell-out at any point in the CGI script or in one of your modules. In this case, anything executed as a separate shell process might be subject to a fully different %ENV (because it's a separate child process).

As others have said, without precious information all we can do is speculate.

Thanks for the great ideas, all!

So after following many a rabbit trail, it turns out the reason %ENV was different was that the cgi script was being called by a PHP exec() command! There was apparently some PHP setup on the old server that allowed the exec() to pass the environment onto the CGI script, but since I compiled everything from source on the new box, that setup was no longer available. (It worked on the old server, but probably wasn't all that secure)

If anyone gives half a **** about PHP (which I'm not sure I do), the solution was to pass the needed ENV variables in the exec command before the cgi script:

Now that's done, I'm back to Perl like any respectable coder ;)