Is my Perl script grabbing environment variables from "someplace else"?

On a Solaris box in a "mysterious production system" I'm running a Perl script that references an environment variable. No big deal.

The contents of that variable from the shell both pre- and post-execution are what I expect.

开发者_如何学运维

However, when reported by the script, it appears as though it's running in some other sub-shell which is clobbering my vars with different values for the duration of the script.

Unfortunately I really can't paste the code. I'm trying to get an atomic case, but I'm at my wit's end here.

---

Is it possible that your script or any libraries that you are 'use'-ing mess around with the %ENV hash?

---

Can you run the code through the Perl debugger to see where it's going? Can you dump the pid ($$) to check if it is forking or invoking subshells?

Alternatively, you could sprinkle print statements throughout the code to narrow down at what point the environment variable is being altered, or start stubbing out components that are not likely to be relevant to hone in on the trouble spot.

---

1) What version of Perl?

2) Some environment variables can be clobbered by child processes, I believe. Can you do a ps?

---

Ok, here's what was going on:

perl itself was a red herring entirely.

The script was executing in a child shell which, when created, was re-loading rc files. Those rc files were blowing away the environment variables I had manually added during the parent shell with reference copies.

I was able to demonstrate this with a simple csh script that just echoed just echoed the environment.

De-wonkifying my rc files (which were overwrought with wonkitude) cleared up the mystical replacement.

UPDATE: The test that proved this was a "test.sh" that had a simple "set" command. It proved that the sub-shell wasn't inheriting the parent environment correctly. Oddly, when I switched my parent interactive shell to ksh, the environment began inheriting correctly.