保存 Perl Windows 环境键大写
我有一个用 Perl 编写的框架,它设置了一堆环境变量来支持进程间(通常是子进程)通信。 我们在 XML 文件中保存一组键/值对。 我们尝试将键名称设为驼峰式 somethingLikeThis
。 这一切都运作良好。
最近我们有机会将控制(链)进程从 Windows 传递到 UNIX。 当我们从 Windows 将 %ENV
哈希输出到文件时,somethingLikeThis
键将变为 SOMETHINGLIKETHIS
。 当 Unix 进程获取文件并重新加载环境并查找 $ENV{somethingLikeThis}
的值时,它不存在,因为 UNIX 区分大小写(从 Windows 端来看,相同的代码可以正常工作) 。
此后我们返回并将所有键更改为大写并解决了问题,但这很乏味并且给用户带来了痛苦。 有没有办法让 Windows 上的 Perl 保留环境哈希键的字符大小写?
I have a framework written in Perl that sets a bunch of environment variables to support interprocess (typically it is sub process) communication. We keep a sets of key/value pairs in XML-ish files. We tried to make the key names camel-case somethingLikeThis
. This all works well.
Recently we have had occasion to pass control (chain) processes from Windows to UNIX. When we spit out the %ENV
hash to a file from Windows the somethingLikeThis
key becomes SOMETHINGLIKETHIS
. When the Unix process picks up the file and reloads the environment and looks up the value of $ENV{somethingLikeThis}
it does not exist since UNIX is case sensitive (from the Windows side the same code works fine).
We have since gone back and changed all the keys to UPPERCASE and solved the problem, but that was tedious and caused pain to the users. Is there a way to make Perl on Windows preserve the character case of the keys of the environment hash?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
据我所知,在 Windows 和 *NIX 世界中,推荐使用 ALL_CAPS 作为环境变量。 我的猜测是 Perl 只是使用某种遗留 API 来访问环境,因此只检索变量的大写名称。
无论如何,您永远不应该依赖这样的东西,更不用说如果您要求用户设置变量,想象一下简单的拼写错误变量会产生多少麻烦和混乱! 您必须记住,一些将保持无名的操作系统尚未学会如何处理区分大小写的文件......
As far as I remember, using ALL_CAPS for environment variables is the recommended practice in both Windows and *NIX worlds. My guess is Perl is just using some kind of legacy API to access the environment, and thus only retrieves the upper-case-only name for the variable.
In any case, you should never rely on something like that, even more so if you are asking your users to set up the variables, just imagine how much aggravation and confusion a simple misspelt variable would produce! You have to remember that some OSes that will remain nameless have not still learned how to do case sensitive files...
首先,为了解决您的问题,我相信在 set 周围使用反引号并自己解析它会起作用。 在我的 Windows 系统上,这个脚本运行得很好。
在camel book中,第25章:Portable Perl,系统交互部分的建议是“不要依赖于%ENV中存在的特定环境变量,并且不要假设%ENV中的任何内容都会区分大小写或大小写不要假设环境变量具有 Unix 继承语义;在某些系统上,它们可能对所有其他进程可见。”
First, to solve your problem, I believe using backticks around set and parsing it yourself will work. On my Windows system, this script worked just fine.
In the camel book, the advice in Chapter 25: Portable Perl, the System Interaction section is "Don't depend on a specific environment variable existing in %ENV, and don't assume that anything in %ENV will be case sensitive or case preserving. Don't assume Unix inheritance semantics for environment variables; on some systems, they may be visible to all other processes."
Jack M.:同意,这在 Windows 上不是问题。 如果我创建一个环境变量 Foo,我可以在 Perl 中将其引用为 $ENV{FOO} 或 $ENV{fOO} 或 $ENV{foo}。 问题是:我将其创建为 Foo 并将整个 %ENV 转储到文件中,然后从 *NX 读取文件以重新创建环境哈希并使用相同的脚本引用 $ENV{Foo},该哈希值不存在($ENV{FOO} 确实存在)。
我们采用了 davidg 建议的全部大写的解决方法。 我只是想知道在 Windows 上从 Perl 写出 %ENV 哈希值的键时是否有任何方法可以“保留大小写”。
Jack M.: Agreed, it is not a problem on Windows. If I create an environment variable Foo I can reference it in Perl as $ENV{FOO} or $ENV{fOO} or $ENV{foo}. The problem is: I create it as Foo and dump the entire %ENV to a file and then read in the file from *NX to recreate the Environment hash and use the same script to reference $ENV{Foo}, that hash value does not exist (the $ENV{FOO} does exist).
We had adopted the all UPPERCASE workaround that davidg suggested. I was just wondering if there was ANY way to "preserve case" when writing out the keys to the %ENV hash from Perl on Windows.
据我所知,没有。 看来您最好使用另一个哈希而不是 %ENV。 如果您正在调用许多外部模块并希望在它们之间跟踪相同的变量,那么工厂模式可能会起作用,这样您就不会破坏 DRY,并且能够在多个模块之间使用区分大小写的散列。 唯一的技巧是保持工厂中所有对象的这些变量更新,但我相信你可以解决这个问题。
To the best of my knowledge, there is not. It seems that you may be better off using another hash instead of %ENV. If you are calling many outside modules and want to track the same variables across them, a Factory pattern may work so that you're not breaking DRY, and are able to use a case-sensitive hash across multiple modules. The only trick would then be to keep these variables updated across all objects from the Factory, but I'm sure you can work that out.
我相信你会发现Windows环境变量实际上是不区分大小写的,因此按键都是大写以避免混淆。
这样,没有任何区分大小写概念的 Windows 脚本就可以使用与其他脚本相同的变量。
I believe that you'll find the Windows environment variables are actually case insensitive, thus the keys are uppercase in order to avoid confusion.
This way Windows scripts which don't have any concept of case sensitivity can use the same variables as everything else.