10 个实验搞懂命令提示符
前言
相信，很多小伙伴儿都在命令提示符中执行过 ipconfig 查看 ip 信息。我们还可以执行 ping ip 来 ping 对应的 ip 地址，执行 notepad 启动记事本，执行 explorer 启动文件管理器……
但是，你好奇过背后的运作机制吗？为什么输入几个简单的几个字母就能启动外部程序，本文试图通过一系列实验来挖掘其背后的运作机制。
如果你对下面的问题有很明确的答案，本文不是为你准备的。如果有模糊，拿不准的地方，请耐心读完。如果觉得有用，请帮忙点个在看，拜谢。
Five Questions
1、在命令提示符里输入 notepad，是哪个位置的记事本被启动了？跟什么有关？
2、如果同一个目录下有两个名为 bcn 的文件，一个是 bcn.com, 一个是 bcn.exe。在命令提示符中输入 bcn 会执行哪个？受什么影响？
3、你知道怎么让自己的程序可以直接在命令提示符中被启动吗？像执行 ipconfig 那样。
4、如果 PATH 环境变量是空的，会有什么问题？
5、如果 PATHEXT 变量是空的，会有什么问题？
PATH 实验
**实验1：**在命令提示符中输入一个不存在的命令（比如，bcn），使用 process monitor 观察整个过程。
如我们所料，找不到。结果如下图：
在观察 process monitor 捕获的日志之前，我们先查看当前命令提示符的当前路径（ Current Directory）和 PATH 环境变量的值。
下图是使用 process monitor 捕获的事件，已过滤无关信息。
红色高亮部分是当前路径相关的事件，黄白相间的部分是 PATH 环境变量相关的事件。
从此可以比较有信心的猜测：在命令提示符中输入命令会先在当前路径下查找，再到 PATH 环境变量指定的路径依次查找。
实验2： 添加一个不存在的路径到 PATH 环境变量中，再次观察整个过程。
:: 更新 PATH 环境变量
set PATH=%PATH%d:
ot_existed_folder
:: 执行命令
bcn当前路径没变，而对应的 PATH 已经多了一条 d:
ot_existed_folder，如下图：
下图是使用 process monitor 捕获的相关事件（已过滤无关事件）。跟上面的实验对比，发现只多了黄色高亮部分。
注意对比上图中黄色和红色部分。红色部分对应的路径是存在的，所以有三条记录。黄色部分对应的路径是不存在的，只有一条记录。可以双击某条记录，查看对应的调用栈。相信查看过调用栈后，你会和我一样，对 Operation 这一列有一个新的认识。
实验3： 把 bcn.exe 放到当前路径（ C:UserscnDesktop）下，执行 bcn。
从上图可知，启动的是 C:UserscnDesktopcn.exe，因为在当前路径下就找到了对应的程序，所以并没有到 PATH 环境变量指示的路径中查找。
实验4： 删除 C:UserscnDesktopcn.exe，把 bcn.exe 放到 PATH 环境变量中的 c:windows 下，再次执行 bcn。
从上图可知，启动的是 C:Windowscn.exe，在当前路径下没找到，然后依次到 PATH 环境变量指示的路径中查找，在c:windows 下找到了对应的程序。
实验5： 清空 PATH 环境变量，在命令提示符中输入 ipconfig，看看是否能正常运行。
结论：
通过以上几个实验，我们知道了在命令提示符中执行一个命令时的查找顺序是：当前路径，PATH 环境变量中指定的路径（按出现顺序进行查找）。
PATHEXT 实验
相信有细心的小伙伴儿发现了，在上面的 实验3 和 实验4 中，会先查找 bcn.COM，没找到才继续查找的 bcn.exe。为什么是这种行为呢？跟什么有关呢？我们看下 PATHEXT环境变量的值，如下图：
我们发现 .COM 出现在 .EXE 之前，是不是这个原因呢？让我们做实验来验证。
实验6： 观察 PATHEXT 是否会影响查找结果。
调整 PATHEXT 的值为 .BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.EXE;.COM，如果查找了前面的几个后缀，而没查找 .COM，说明 PATHEXT 会影响查找结果。
set PATHEXT=.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.EXE;.COM
bcnprocess monitor 捕获的事件验证了我们的猜测。截图：
实验7： 观察 PATHEXT 时的行为。
清空 PATHEXT，再执行 bcn。
set PATHEXT=
bcnprocess monitor 捕获相关事件如下图：
有点意外，原本以为会执行失败。看来如果 PATHEXT 是空，会使用默认的 PATHEXT，默认的 PATHEXT 是什么呢？
实验8： 观察默认的PATHEXT 。
重命名 bcn.exe 为 bcn.xyz（很重要），然后执行下面的命令：
set PATHEXT=
bcnprocess monitor 捕获相关事件如下图：
在我的系统（win10 1903）中，当 PATHEXT 为空时，默认搜索的扩展名是 .COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC;。其它系统可能有不同的行为，感兴趣的小伙伴儿请自行实验。
实验9： 当前目录下同时存在 bcn.com 和 bcn.exe 会执行哪个？（通过上面的实验，结论很明显了）
分别执行下面两组命令，观察对比结果：
set PATHEXT=.COM;.EXE
bcnset PATHEXT=.EXE;.COM
bcnprocmon 捕获的两次查找过程对比图，黄色是设置 .COM 优先的结果，红色是设置 .EXE 优先的结果。
从结果可以进一步确定，优先查找 PATHEXT 中先出现的后缀名。
**实验10：**观察直接执行 bcn.exe 观察查找过程。
如果命令中带后缀，那么查找的时候不会依赖 PATHEXT ，会直接执行给定的命令。
实验代码
如果你也想自己动手实验。可以新建一个工程，并粘贴下面的代码，编译生成测试程序。
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include "stdlib.h"
int main(int argc, char* argv[])
{
char exe_path[MAX_PATH] = { 0 };
::GetModuleFileNameA(NULL, exe_path, MAX_PATH);
printf("%s
", exe_path);
system("pause");
return 0;
}总结
相信通过上面一系列的实验，我们对命令提示符如何执行一个外部命令有了深刻的认识。对 PATH 和 PATHEXT 这两个环境变量的作用，简单总结如下：
PATH决定了外部命令所在位置的查找顺序，PATHEXT决定了外部命令的扩展名查找顺序。- 当我们在命令提示符中输入一个命令时，会先到当前路径（
Current Directory）中查找，如果找不到，才会到环境变量PATH指示的路径中查找。 - 如果输入的命令不带后缀，那么会根据
PATHEXT指示的后缀顺序依次拼接成完整名称再查找。 - 如果输入的命令带后缀，不会根据
PATHEXT中的后缀查找。 - 如果我们想让自己的程序也能直接通过命令提示符启动，我们可以把程序所在路径添加到
PATH环境变量中，位置越靠前，越有可能被执行。 - 如果
PATHEXT为空，那么会使用默认的PATHEXT，我机器上的值是.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC;。