我的 Perl 脚本是否从“其他地方”获取环境变量？
在“神秘生产系统”的 Solaris 机器上，我正在运行引用环境变量的 Perl 脚本。没什么大不了的。
执行前和执行后 shell 中该变量的内容都是我所期望的。
然而，当脚本报告时，它看起来好像在其他一些子 shell 中运行，这些子 shell 在脚本持续时间内用不同的值破坏我的变量。
不幸的是我真的无法粘贴代码。我正试图找到一个原子案例，但我已经无计可施了。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的脚本或您正在“使用”的任何库是否有可能与 %ENV 哈希值混淆？
Is it possible that your script or any libraries that you are 'use'-ing mess around with the %ENV hash?
您可以通过 Perl 调试器运行代码来查看它的去向吗？您可以转储 pid (
$$) 以检查它是否分叉或调用子 shell 吗？或者，您可以在整个代码中散布 print 语句，以缩小环境变量被更改的范围，或者开始删除那些与故障点无关的组件。
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) Perl 是什么版本？
2）我相信，某些环境变量可能会被子进程破坏。可以ps一下吗？
1) What version of Perl?
2) Some environment variables can be clobbered by child processes, I believe. Can you do a ps?
好吧，事情是这样的：
perl 本身完全是一个转移注意力的东西。
该脚本在子 shell 中执行，该子 shell 在创建时会重新加载 rc 文件。这些 rc 文件破坏了我在父 shell 中手动添加的环境变量和参考副本。
我能够使用一个简单的 csh 脚本来演示这一点，该脚本只是回显环境。
解除我的 rc 文件（由于狂妄而过度劳累）清除了神秘的替代品。
更新：证明这一点的测试是一个“test.sh”，它有一个简单的“set”命令。事实证明，子 shell 没有正确继承父环境。奇怪的是，当我将父交互式 shell 切换到 ksh 时，环境开始正确继承。
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.