让 Win + R 运行自定义命令:一个“加入 PATH”的小脚本
Windows 的 Win + R 很好用,但多数时候,我们只拿它运行 cmd、ncpa.cpl、mstsc、services.msc 这些系统自带命令。
其实,只要把自己的工具目录加入 PATH,也能通过 Win + R 运行。
比如我自己长期使用的自定义/第三方工具:
hosts.cmd 打开 hosts 文件
git1.cmd 使用 SSH Key 1 调 Git 命令
git2.cmd 使用 SSH Key 2 调 Git 命令(多 Git 上游账号管理)
vps1.cmd SSH 登录 VPS 1
vps2.cmd SSH 登录 VPS 2
bun JavaScript 运行环境
uv Python 包/项目管理工具
……
portrule.cmd 快速管理 Windows 防火墙端口放行
porttask.cmd 根据服务端口查进程
taskport.cmd 根据进程 ID 查服务端口
psping.exe Sysinternals TCP ping 工具
tcpview.exe Sysinternals 连接查看
Autoruns.exe Sysinternals 启动项排查
不用打开开始菜单,不用找快捷方式,不用切到某个目录,只要记住命令名。
核心机制就是 PATH。
当你输入一个命令时,系统会在 PATH 记录的目录里依次查找对应的 .exe、.cmd、.bat 等可执行文件。只要某个目录在 PATH 里,这个目录里的脚本和工具,就能像系统命令一样被调用。
所以关键问题就变成了:
怎样快速把一个目录加入 PATH?
一、我做了两个小脚本
PathHereAdd.cmd 加入用户 PATH
PathHereRemove.cmd 从用户 PATH 移除
两个脚本只作用于自身所在目录,并且明确拒绝参数,避免“当前工作目录”和目标目录不一致。
脚本已上传 GitHub,仓库地址见文末。
使用方法:
- 克隆
swaw-kit仓库,例如放在C:\swaw-kit - 双击
PathHereAdd.cmd
这时脚本会检查这个工具箱目录,是否已经在当前用户的 PATH,不存在就追加进去。
之后,打开新终端,或者重新调起 Win + R,就会生效了。
要撤销,只需双击同目录中的 PathHereRemove.cmd,它会执行 PathHereAdd.cmd 的反向操作。
二、会不会改坏 PATH?
PATH 是重要的环境变量,脚本在追加/移除其中目标项时,做了几层保护:
1. 只修改当前用户 PATH,不碰系统 PATH
2. 添加前检查是否已存在,避免重复加入
3. 写入前备份原始用户 PATH
4. 只改要追加/删除的目录项;其他仍按原样保留(例如 `%USERPROFILE%\bin` 这种,不会被展开成固定路径)
5. 支持空格、中文、&、%、!、括号等路径字符
6. 删除时把 `PATH` 按分号拆成一个个目录项,再做完整项匹配;所以删除如 `C:\Tools` 时,不会误伤 `C:\ToolsExtra`。
7. 如果同一个目录重复出现,删除脚本会把所有匹配项都清掉。
8. `data/PathHere.backup.log` 中保存每次操作前备份的原始用户 `PATH`,可做最后保障。
PATH本身用分号分隔目录项,所以工具箱目录名不要包含分号。
三、它真正改变的不是 PATH
这个脚本很小,真正有用的是它带来的工作方式变化。比如我就维护了一个工具箱目录:
C:\swaw-kit
把常用命令、自己写的 .cmd 快捷脚本都放进去。这样 Win + R 后,敲入它们的文件名,回车,就启动了。
当然,在命令行窗口(终端)里直接输文件名,也一样能调用。
四、边界和风险
修改环境变量后,已经打开的终端通常不会自动刷新。新开的终端、新启动的程序,才会读取新的用户环境变量。
不建议把很多目录都加入
PATH。最好只加一个稳定的工具箱目录,用作自己的命令空间;目录多了,反而容易出现命令名冲突。
小结
这个脚本不是复杂工具,但它很像一个入口开关。
把高频动作变成命令;把命令放进一个稳定目录;再用 Win + R、终端或其他脚本统一调用。
对我来说,这不是在折腾 PATH,而是在给 Windows 补一个自己的操作层。
脚本仓库地址:swawai/swaw-kit
