向用户 PATH 添加目录不起作用?

ant*_*a40 3 windows-7 path

我刚刚在我的 Windows 系统上安装了 gvim(无论如何它都在 C:\gvim 上)。然后我在用户路径上添加 C:\gvim\vim73\,而不是系统路径。之后,我尝试从命令提示符调用 vim。不,它没有用。所以我从用户 PATH 到系统 PATH 中删除了 gvim 目录。它确实有效。

我还是很好奇,所以我做了一个“echo %PATH%”,结果是系统PATH中的一切。

我的理解是系统 PATH 的优先级高于用户,因此 Windows 将首先尝试搜索系统 PATH,然后搜索用户的。所以它应该有效,但它没有。

Jde*_*eBP 8

当您修改注册表时,您实际上并未设置任何形式的任何环境变量。

环境变量不保存在注册表中。注册表中保存的是一个模板,当收到通知时,Windows 资源管理器等程序(重新)从中构建它们的环境变量。实际的环境变量是针对每个进程的,并存储在每个进程自己的地址空间中,最初是从其父进程继承的,此后可以随心所欲地进行修改。像 Windows 资源管理器这样的程序参与了一个自愿协议,他们将重新读取模板,并在Windows 消息广播到桌面上的所有(顶级)窗口时更新他们自己的每个进程的环境

许多 Win32 程序不参与此自愿协议。微软的命令解释器就是这样一种程序。到运行Microsoft命令解释的过程中修改的环境变量,一个用途的普通命令解释命令用于修改环境变量,例如SETDPATH,和PATH。命令解释器产生的每个进程都将继承修改后的环境。

同样,Windows 资源管理器进程中修改后的环境仅由 Windows 资源管理器收到消息并重新读取模板产生的进程继承。已运行进程的环境变量不受其他进程对其自身环境变量所做的修改的影响。一个已经运行微软的命令解释器不会奇迹般地获得改变的环境从Windows资源管理器的过程,改变之前催生了它。

其他命令解释器有所不同。 例如,JP Software 的 TCC本身就参与了自愿协议。当启用“系统更改更新环境”设置时,它将识别 Windows 消息,并从注册表中的模板更新其自己的每进程环境。