Windows 环境变量嵌套的限制？
那么，Windows 中环境变量的嵌套深度是否有限制呢？我做了很多开发工作，并且正在尝试设置我的开发环境变量，其中很多都是相互嵌套的，即。
GLEW=%THIRD_PARTY_ROOT%\GLEW
GLEW_1_5_5=%GLEW%\glew-1.5.5
GLEW_BIN_PATH=%GLEW_ROOT%\bin
GLEW_INCLUDE_PATH=%GLEW_ROOT%\include
GLEW_LIB_PATH=%GLEW_ROOT%\lib
GLEW_ROOT=%GLEW_1_5_5%
OSG=%THIRD_PARTY_ROOT%\OpenSceneGraph
OSG_2_8_3=%OSG%\OpenSceneGraph-2.8.3
OSG_BIN_PATH=%OSG_ROOT%\bin
OSG_INCLUDE_PATH=%OSG_ROOT%\include
OSG_LIB_PATH=%OSG_ROOT%\lib
OSG_ROOT=%OSG_2_8_3%
THIRD_PARTY_ROOT=C:\dev\third-party
但我很难让它们真正正确地扩展。有一段时间，当我查看 set 的输出时，我发现它们看起来像是按顺序扩展的，因此任何依赖于 foo_ROOT 的输出都没有正确扩展。我尝试启用延迟扩展，但这没有帮助，但重新启动似乎...所以延迟扩展可能需要重新启动。
无论哪种方式，我的 PATH 变量中有 GLEW_BIN_PATH 和 OSG_BIN_PATH 并且它们拒绝扩展。这真的很令人沮丧，因为 dll 驻留在那里，当然我可以得到任何其他东西来扩展......有什么想法吗？
编辑：我将它们放在 PATH 变量中：
[everything else....];%GLEW_BIN_PATH%;%OSG_BIN_PATH%所以我没有看到明显的原因来阻止它们扩张。
So, is there a limit to how deeply environment variables can be nested in Windows? I do a lot of development work and I'm trying to set up my development environment vars, and a lot of them nest off each other, ie.
GLEW=%THIRD_PARTY_ROOT%\GLEW
GLEW_1_5_5=%GLEW%\glew-1.5.5
GLEW_BIN_PATH=%GLEW_ROOT%\bin
GLEW_INCLUDE_PATH=%GLEW_ROOT%\include
GLEW_LIB_PATH=%GLEW_ROOT%\lib
GLEW_ROOT=%GLEW_1_5_5%
OSG=%THIRD_PARTY_ROOT%\OpenSceneGraph
OSG_2_8_3=%OSG%\OpenSceneGraph-2.8.3
OSG_BIN_PATH=%OSG_ROOT%\bin
OSG_INCLUDE_PATH=%OSG_ROOT%\include
OSG_LIB_PATH=%OSG_ROOT%\lib
OSG_ROOT=%OSG_2_8_3%
THIRD_PARTY_ROOT=C:\dev\third-party
But I was having a heck of a time getting them to actually expand properly. For a while when I looked at the output of set, I was just getting what looked like they were being expanded in order and so any ones that depended on foo_ROOT weren't being expanded properly. I tried enabling delayed expansion and that didn't help, but restarting seemed to... so maybe delayed expansion required a restart..
Either way, I have GLEW_BIN_PATH and OSG_BIN_PATH in my PATH variable and they refuse to expand. This is really frustrating because the dll's are residing there and of course I can get evvvverything else to expand... any thoughts?
Edit: I have them in the PATH variable as:
[everything else....];%GLEW_BIN_PATH%;%OSG_BIN_PATH%So I'm not seeing an obvious cause to keep them from expanding out..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
看起来变量定义存在字典顺序依赖性。
Windows 按字典顺序扩展并填充环境变量 (:-O)
您只能在您的变量上使用“字典顺序”低于您的变量的变量。
例子：
以下定义：
产生
但
产生
到期 VAR_03 未在扩展 VAR_02 时定义。
It looks like there is a lexicographic dependency on the variables definition.
Windows expands and populates the Enviroment Variables on lexicographic order (:-O)
You can only use on your variable, variables that are "lexicographically" lower than your variable.
Example:
Following Definition:
Produces
But
Produces
Due VAR_03 is not defined when VAR_02 is expanded.
是的，这让我发疯。完整重现：
系统属性，环境变量，设置如下：
然后单击“确定”，然后运行 cmd。这是我看到的：
此链接解释了 Vista，但没有提到它发生在 Win7 上。
http://support.microsoft.com/kb/911089
...乔纳斯
Yeah, this is driving me crazy. Full repro by:
System Properties, Environment Varialbles, set up like so:
Then click OK, and run cmd. Here's what I see:
This link explains for Vista, but does not mention that it happens on Win7.
http://support.microsoft.com/kb/911089
...Jonas
我已经成功地转义了百分号：
当从Windows环境变量窗口查看变量时，它将显示为
GLEW | %THIRD_PARTY_ROOT%\GLEW注意： 双百分号仅在脚本内有效。如果在命令行上使用，请使用脱字符转义字符（例如
GLEW=^%THIRD_PARTY_ROOT^%\GLEW）。I've had success with escaping the percent sign:
When viewing the variable from the Windows Environment Variable window, it will display as
GLEW | %THIRD_PARTY_ROOT%\GLEWNote: The double percent signs will only work inside a script. If using on the command line, use the caret escape character (e.g.
GLEW=^%THIRD_PARTY_ROOT^%\GLEW).您是否也将所有需要的变量保存在系统变量中？因为为了扩展这些值，系统必须拥有所有所需变量的“永久”内存。
如果您在命令行上连续执行所有这些操作，只需说
X=something和Y=%X%;else，那么当您将路径设置为 < code>PATH=%PATH%;%Y%，shell 在保存 PATH 的新值之前扩展所有变量的值；但是一旦您关闭命令提示符窗口，系统就完全忘记了％X％和％Y％。但是，如果您使用系统属性控制面板将 PATH 设置为包含未展开的变量，那么在重新启动时所有这些变量都必须作为系统变量存在，否则它们将无法展开。
要确保保存系统中的所有变量以便它们在重新启动后仍然存在，请使用系统属性控制面板或 SETX.EXE 命令。如果您打算在系统路径（不仅仅是您的用户帐户的路径）中使用它们，那么您将需要使用
SETX /MX=blah或系统属性 | 的底部部分。环境变量选项卡，标记为“系统变量”。Have you saved all of the needed variables in the System Variables as well? Because in order to expand the values, the system will have to have a "permanent" memory of all the needed variables.
If you do all these together in a row on the command line, just saying
X=somethingandY=%X%;else, then when you set the path toPATH=%PATH%;%Y%, the shell expands the values of all the variables before it saves the new value of PATH; but as soon as you close the Command Prompt window, the system has forgotten %X% and %Y% entirely.However, if you use the System Properties Control Panel to set the PATH to include the unexpanded variables, than all those variables are going to have to exist as system variables when you reboot, or they'll fail to expand.
To ensure that you are saving all the variables in the system so that they are still there after the reboot, either use the System Properties Control Panel or the SETX.EXE command. If you are going to use them in the system PATH (not just your user account's path), then you'll want to use
SETX /M X=blahor the bottom part of the System Properties | Environment Variables tab, labeled "System variables".我在 Windows 10 build 1903 中遇到过这种情况。
对我来说，解决方案是从“用户”（系统属性对话框的上半部分）中删除
PATH变量，并仅保留路径'系统'。重新启动 cmd.exe shell 或使用refreshenv重新加载属性，扩展应该会再次起作用。这看起来像是 Windows 中的一个错误，因为它如何解析用户与系统属性，或者可能是处理顺序。对我来说，它不会用“系统”环境变量集中的值替换用户路径中的值。如果所有变量都在用户中，它可能会工作得更好，但我还没有测试这个假设。
I have been experiencing this in Windows 10, build 1903.
For me, the solution was to remove the
PATHvariable from 'user' (the upper half of the system properties dialog) and keep only the path in 'system'. Restart the cmd.exe shell or userefreshenvto reload the properties, and expansion should work again.This looks like a bug in Windows for how it resolves user vs system properties, or possibly the processing order. For me it was not replacing values in the user PATH with values from the 'system' set of env vars. It might work better if all the variables are in user, but I've not tested this hypothesis.