Windows 中的环境变量 Path 的作用

设置 Windows 环境变量

  关于设置 Windows 环境变量的方法，可见笔者的另一篇博客：

  设置 Windows 环境变量的方法：
https://blog.csdn.net/wangpaiblog/article/details/113532591

Windows 中的环境变量 Path 的作用

  简单地说，Windows 中的环境变量 Path 是用来指定可执行文件的绝对路径。

  可执行文件可以通过在 Windows 中的 CMD 来运行，但是在一般情况下，这需要输入该可执行文件的全路径。举个例子，如果谷歌浏览器的快捷方式的路径如下图所示，

  （注意：可执行文件并不仅限于.exe文件，它还可以是.bat、.cmd等）

  那么，在 CMD 中输入chrome.exe的全路径（可以省略chrome.exe的后缀.exe）就可以直接运行谷歌浏览器了，如下图所示：

  如果在环境变量 Path 中设置了chrome.exe的上一级文件夹的路径（注意：是chrome.exe的上一级文件夹的路径，不是chrome.exe自身的全路径），实际上直接输入 chrome（可以省略chrome.exe的后缀.exe）就可以运行谷歌浏览器了，如下图所示：

  （注意：设置完环境变量之后，必须重启 CMD 才会在 CMD 中生效）

  （很早以前，有些外行人喜欢用这种方法来炫技，希望读者不要模仿，因为使用这种方式和直接双击快捷方式没有区别）

  这就是说，如果在环境变量 Path 中设置了某路径，则运行该路径下的可执行文件时，可以直接输入该文件的无后缀名称来运行，这一点和相对哪个路径下启动 CMD 无关。这虽然对普通人没有什么大的用处，但对于编程开发人员来说就不是这样。因为如果在环境变量 Path 中设置了某路径，那么无论在哪个工程目录下输入命令，该命令都可以被识别并且执行。

  反过来，如果想知道 CMD 中可输入的命令所对应的文件路径，可以使用命令 where，如：

  实际上，where 这个命令本身的路径也可以通过 where 这个命令本身来找到。

  之所以会这样，是因为 CMD 非常原始。如果有使用过多种操作系统的经历的读者应该知道，像 CMD 这种由操作系统提供的专门用来输入命令的玩意儿，在本质上只能做一件事情，那就是执行本操作系统能够执行的可执行文件。也就是说，在 CMD 中输入的所有的命令都在电脑上对应着一个同名可执行文件（比方说，CMD 本身在电脑上也有对应的 .exe 文件），所谓的命令，也就只是操作系统上某个可执行文件的文件名而已。Windows 的预置命令往往位于目录 C:\Windows\System32\ 下。当在 CMD 中输入字符的时候，它会按照空格尝试将第一个单词解释成可执行程序的文件名，然后按照如下步骤去寻找这个文件。

1. 它首先会判断这个文件名是否包含绝对路径。如果包含绝对路径，那它只会在绝对路径中寻找。此时如果没找到，直接报错。

2. 如果不包含绝对路径，则它会在 CMD 所操作的目录下寻找。

3. 如果没找到，就会操作系统的内置命令中找。

4. 如果还没找到，就会去环境变量 Path 中记载的目录中找到。如果再没找到，CMD 就会报错。

  不过，这里有一个问题，如果在 CMD 使用绝对路径运行程序，但这个绝对路径包含空格该怎么办呢？关于这个问题，可见笔者的另一篇博客：

  解决’C:\Program’ 不是内部或外部命令…：
https://blog.csdn.net/wangpaiblog/article/details/120714934

  命令提示符 CMD 与操作系统一脉相承，它只是操作系统提供给用户的外壳。它只认得可执行文件，不认其它的文件。如果想要 CMD 能够间接解析其它文件，需要先写一个能解析其它文件的程序，然后用 CMD 运行它。

后记：操作系统如何打开非可执行文件

  等阅读完前面的内容，有的读者很敏锐：Windows 上的可执行文件是一种 非文本文件，这种文件类型只占我们日常能直接打开的文件中的一部分。那么，像一些 非可执行文件，如 txt、docx、png、mp4 等等，按照前面的说法，为什么我们可以直接打开这种 非可执行文件 呢？

  实际上，打开这种 非可执行文件 也只是打开其所对应的 可执行文件 而已，Windows 实际上并没有“打开”这种 非可执行文件 的功能。打开 非可执行文件 也是由 Windows 打开的 可执行文件（也就是软件。为了方便描述，下面将会把 可执行文件 用 软件 一词代替。），由这个软件自己决定读取用户点击的 非可执行文件 而已。记住，操作系统本质上只能直接运行可执行文件。

  直接打开一种 非可执行文件 之所以可行，是因为事先为其绑定了默认与之关联的一个软件。然后在用户打开一种 非可执行文件 时，Windows 会打开其绑定的软件，并将用户打开的 非可执行文件 的路径传给它。后面，这个软件会选择干什么，就是这个软件自己的事了，跟操作系统没关系。通常这个软件会解析这种文件的内容。因此，当用户“打开”一个 非可执行文件 时，实际上打开的是一个软件，Windows 上显示的也是这个软件的界面，这个文件被解析并渲染后的内容。

  既然操作系统自带的功能这么原始，Windows 如何知道一个文件是什么类型呢？如何知道它是不是可执行文件呢？方法也很简单粗暴——直接通过文件后缀来判断的。它非常相信用户，它认为用户的文件名后缀代表的文件类型信息是正确的。

  因此，如果读者想自己发明出一种文件类型，然后同时使得这种文件类型能在 Windows 上直接打开。可以定义一种新的文件后缀，并编写一个解析这种文件的软件（最好含 GUI 界面），然后绑定这种文件的打开方式即可。而如果同时想变得高级，使得这种软件变成命令，直接在 Path 中设置这个软件的绝对路径即可。方法前面已讲过，此处不再累述。

  因此，一个文件的打开效果实际上是由其绑定的软件决定的。因此，只需要更改一种文件类型的绑定软件，就可以改变这种文件的解析和渲染方式。

  一般来说，操作系统会为一些基本的 非可执行文件 绑定读取它的 可执行文件，比如 txt 文件，默认绑定的是 notepad（记事本）。而 notepad 一般在 Windows 安装时就已经自带了，且这种 txt 文件 打开的关联自动就配置好了，所以不需要用户自行配置。

  以 notepad 为例，找到它的方式有很多，如下所示。

  有炫技倾向的读者也可以使用如下方式。

  可以看出，notepad.exe 位于 C:\Windows\System32 下，所以它不需要出现在环境变量 Path 中也可以起作用。

  承笔者前面所言，用如下方式也可以打开一个 txt 文件。实际上，读者平时双击打开 非可执行文件 就是这种原理。

  如果读者感兴趣，这里还可以讲得更深入一点。操作系统运行命令的原理是，第一个单词会解释成命令，这最终会解析成可执行文件的路径。从第二个的单词开始，后续的内容会解释成此命令的参数，并传给被执行的程序。一个程序的主函数通常在一开始运行时就会接收到这些参数，如下图所示。这种参数接口可不是 Java 程序才有，各个编程语言通常都提供了，只是读者平时没有留意而已。实际上，这种命令的语法类似于函数调用，所谓的函数式编程的可行性就是基于此。

  因此，当用户打开 txt 文件时，实际上打开的是 notepad，然后 Windows 会将该 txt 文件的绝对路径作为命令参数传给 notepad。这样，notepad 在后台通过绝对路径读取该 txt 文件，然后在 GUI 界面上渲染它，最终就变成了读者平时所看到的内容。