搞懂Windows命令提示符

前言

相信，很多小伙伴儿都在命令提示符中执行过 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 观察整个过程。

如我们所料，找不到。结果如下图：

can-not-find-bcn

在观察 process monitor 捕获的日志之前，我们先查看当前命令提示符的当前路径（ Current Directory）和 PATH 环境变量的值。

current directory的值

PATH环境变量的值

下图是使用 process monitor 捕获的事件，已过滤无关信息。

procmon-filter-event-bcn

红色高亮部分是当前路径相关的事件，黄白相间的部分是 PATH 环境变量相关的事件。

从此可以比较有信心的猜测：在命令提示符中输入命令会先在当前路径下查找，再到 PATH 环境变量指定的路径依次查找。

实验2： 添加一个不存在的路径到 PATH 环境变量中，再次观察整个过程。

:: 更新 PATH 环境变量set PATH=%PATH%d:not_existed_folder:: 执行命令bcn

当前路径没变，而对应的 PATH 已经多了一条 d:not_existed_folder，如下图：

path-with-invalid-folder

下图是使用 process monitor 捕获的相关事件（已过滤无关事件）。跟上面的实验对比，发现只多了黄色高亮部分。

procmon-filter-event-with-not_existed_folder

注意对比上图中黄色和红色部分。红色部分对应的路径是存在的，所以有三条记录。黄色部分对应的路径是不存在的，只有一条记录。可以双击某条记录，查看对应的调用栈。相信查看过调用栈后，你会和我一样，对 Operation 这一列有一个新的认识。

callstack

实验3： 把 bcn.exe 放到当前路径（ C:UsersbcnDesktop）下，执行 bcn。

start-bcn-on-current-folder

从上图可知，启动的是 C:UsersbcnDesktopbcn.exe，因为在当前路径下就找到了对应的程序，所以并没有到 PATH 环境变量指示的路径中查找。

实验4： 删除 C:UsersbcnDesktopbcn.exe，把 bcn.exe 放到 PATH 环境变量中的 c:windows 下，再次执行 bcn。

start-bcn-on-current-folder

从上图可知，启动的是 C:Windowsbcn.exe，在当前路径下没找到，然后依次到 PATH 环境变量指示的路径中查找，在c:windows 下找到了对应的程序。

实验5： 清空 PATH 环境变量，在命令提示符中输入 ipconfig，看看是否能正常运行。

Snipaste_2020-05-05_12-49-10

结论：

通过以上几个实验，我们知道了在命令提示符中执行一个命令时的查找顺序是：当前路径，PATH 环境变量中指定的路径（按出现顺序进行查找）。

PATHEXT 实验

相信有细心的小伙伴儿发现了，在上面的 实验3 和 实验4 中，会先查找 bcn.COM，没找到才继续查找的 bcn.exe。为什么是这种行为呢？跟什么有关呢？我们看下 PATHEXT环境变量的值，如下图：

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;.COMbcn

process monitor 捕获的事件验证了我们的猜测。截图：

pathext-search-order

实验7： 观察 PATHEXT 时的行为。

清空 PATHEXT，再执行 bcn。

set PATHEXT=bcn

process monitor 捕获相关事件如下图：

excute-with-empty-pathext

有点意外，原本以为会执行失败。看来如果 PATHEXT 是空，会使用默认的 PATHEXT，默认的 PATHEXT 是什么呢？

实验8： 观察默认的PATHEXT 。

重命名 bcn.exe 为 bcn.xyz（很重要），然后执行下面的命令：

set PATHEXT=bcn

process monitor 捕获相关事件如下图：

default-pathext

在我的系统（win10 1903）中，当 PATHEXT 为空时，默认搜索的扩展名是 .COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC;。其它系统可能有不同的行为，感兴趣的小伙伴儿请自行实验。

实验9： 当前目录下同时存在 bcn.com 和 bcn.exe 会执行哪个？（通过上面的实验，结论很明显了）

分别执行下面两组命令，观察对比结果：

set PATHEXT=.COM;.EXEbcn 

set PATHEXT=.EXE;.COMbcn

procmon 捕获的两次查找过程对比图，黄色是设置 .COM 优先的结果，红色是设置 .EXE 优先的结果。

compare-load-order

从结果可以进一步确定，优先查找 PATHEXT 中先出现的后缀名。

实验10：观察直接执行 bcn.exe 观察查找过程。

run-with-extension

如果命令中带后缀，那么查找的时候不会依赖 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("%sn", exe_path);  system("pause");  return 0;}

总结

相信通过上面一系列的实验，我们对命令提示符如何执行一个外部命令有了深刻的认识。对 PATH 和 PATHEXT 这两个环境变量的作用，简单总结如下：

  1. PATH 决定了外部命令所在位置的查找顺序，PATHEXT 决定了外部命令的扩展名查找顺序。

  2. 当我们在命令提示符中输入一个命令时，会先到当前路径（Current Directory）中查找，如果找不到，才会到环境变量 PATH 指示的路径中查找。

  3. 如果输入的命令不带后缀，那么会根据 PATHEXT 指示的后缀顺序依次拼接成完整名称再查找。

  4. 如果输入的命令带后缀，不会根据 PATHEXT 中的后缀查找。

  5. 如果我们想让自己的程序也能直接通过命令提示符启动，我们可以把程序所在路径添加到 PATH 环境变量中，位置越靠前，越有可能被执行。

  6. 如果 PATHEXT 为空，那么会使用默认的 PATHEXT，我机器上的值是 .COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC;。

 

以上是 搞懂Windows命令提示符 的全部内容， 来源链接： utcz.com/a/26975.html

回到顶部