Windows 拖拽运行 WSL SH 脚本这件事我一开始以为只是个省几步操作的小玩具真正做完之后才发现它解决的痛点比想象中大得多高频脚本每次都要打开终端、手敲路径、再切目录稍微一个空格或大小写打错整个节奏就被打断。我的做法是用一个批处理文件当拖放接收器把 .sh 直接从资源管理器拖上去自动完成路径翻译、换行符修正、目录切换然后交给 WSL 执行。全程只用 Windows 自带的 wsl.exe、wslpath 和一段十几行的 bat不装任何第三方工具。这篇文章会把原理、完整代码和实测踩过的坑都摊开讲适合已经把 WSL 装好、平时要在 Linux 环境里跑脚本的朋友。1. 高频脚本场景下拖拽运行比开终端快在哪里1.1 原本的运行流程有多折腾我手头有个发布脚本放在D:\project\build-web.sh里面要做构建、压缩、上传开发高峰期每天要跑几十遍。在 WSL 终端里最顺手的操作是cd /mnt/d/project bash build-web.sh听起来也就一行命令。可问题恰恰出在这行命令上目录名一旦带空格、带括号、带中文人脑做路径翻译就特别容易出错。举一个很常见的例子脚本要是放在C:\Users\Me\My Documents\build scripts\deploy.sh它在 WSL 里对应的路径是/mnt/c/Users/Me/My Documents/build scripts/deploy.sh你得手动把所有反斜杠换成斜杠、盘符改挂载点。这个翻译过程只要有一次少敲一个空格shell 就会报错然后整行重打。更要命的是如果脚本本身还要在多个目录间切换每次切换都要重新翻译一遍路径投入产出比非常低。把文件拖到图标上这个动作本质上就是把人做路径翻译这一步彻底拿掉。资源管理器告诉我们文件在哪脚本所在目录就是工作目录剩下的交给程序处理。对我这种一天要触发几十次脚本的人来说省下的不只是打字时间更重要的是不打断思路。1.2 为什么选择批处理 wsl.exe而不是其他方案我最初也考虑过其他几条路。Windows Terminal 可以自定义配置但只是少开一个窗口命令照样要手敲VS Code 的 WSL 集成适合编辑和调试但专门为快速跑个脚本开一个编辑器还是太重在 WSL 里做 alias 或软链接又没法从 Windows 侧把文件拖进去。批处理方案最大的好处是零依赖。wsl.exe 是系统自带的wslpath 是 WSL 内置的路径转换工具批处理本身不需要安装。文件保存下来放到桌面就是一个天然的拖放目标。整个链路非常透明出问题也好排查。1.3 这个方案适合谁不适合谁适合的场景很明确高频固定脚本、需要拿 Windows 文件当输入的脚本、以及你想交给同事使用的傻瓜式入口。不适合的场景也值得说清楚如果你需要频繁给脚本传不同的复杂参数拖拽本身并不提供参数输入框需要额外改造或者直接用终端如果你需要断点调试、看变量环境那 VS Code 的 WSL 调试器仍然是更好的选择。2. 为什么直接 wsl 跑不行wsl.exe 与 wslpath 的基本功2.1 wsl.exe 的调用方式理解这个脚本首先要弄清楚wsl.exe支持的几种调用形态。平时在 cmd 或 PowerShell 里敲wsl是进入交互式 shell而它其实可以直接执行命令命令作用wsl.exe bash xxx.sh在默认发行版里用 bash 执行脚本wsl.exe -d Ubuntu-24.04 -- bash xxx.sh指定发行版执行wsl.exe --cd /mnt/d/project -- bash xxx.sh先切到 WSL 侧的目录再执行wsl.exe -u root -- bash xxx.sh以指定用户身份执行--cd这个参数很关键但后面会讲到它的坑。-d则用于你有多个发行版的场景。批处理里这两者都可以通过变量控制。2.2 反斜杠、盘符和 /mnt 的关系很多人第一次写wsl 运行 Windows 上的脚本时会直接写wsl bash C:\scripts\deploy.sh然后发现报No such file or directory。原因有两层。第一层是路径格式bash 不认识C:\这种写法。WSL 默认把 Windows 的每个盘挂载到/mnt下面C 盘就是/mnt/cD 盘就是/mnt/d所以C:\scripts\deploy.sh在 WSL 里应该是/mnt/c/scripts/deploy.sh。第二层是反斜杠转义在 bash 里反斜杠是转义字符。即使你把路径用双引号包起来C:\scripts\deploy.sh传进 bash 后里面反斜杠依然原样保留结果 bash 把它当成一个相对路径去找自然找不到。所以不能指望把 Windows 路径原样塞给 WSL 进程必须经过翻译。2.3 wslpath官方路径翻译器WSL 自带一个专门做路径翻译的工具叫wslpath位于发行版里的/usr/bin/wslpath。在 Windows 侧可以这样调用wsl.exe wslpath -u C:\foo。几个常用参数我列在下面参数功能示例无参数默认当 Unix 路径转 Windows 路径wslpath /mnt/c/foo-C:\foo-wUnix 路径转 Windows 路径wslpath -w /mnt/c/foo-C:\foo-uWindows 路径转 Unix 路径wslpath -u C:\foo-/mnt/c/foo-mUnix 转 Windows 但用斜杠wslpath -m /mnt/c/foo-C:/foo-a自动判断类型wslpath -a C:\foo-/mnt/c/foo批处理里配合for /f拿到输出结果就完成了路径翻译。这是整个拖拽运行器最核心的环节。3. 完整拖拽运行器代码先跑通一个能用的版本3.1 初版代码不要一上来就上完整版先把通路跑通。下面这个初版只做三件事接收拖拽文件、翻译路径、用 wsl 执行。echo off setlocal EnableDelayedExpansion if %~1 ( echo 请把一个 .sh 脚本拖到我身上。 pause exit /b 1 ) for /f delims %%i in (wsl.exe wslpath -a %~f1) do set SH_FILE%%i if not defined SH_FILE ( echo 路径转换失败请确认 WSL 已安装并能打开。 pause exit /b 1 ) echo 正在执行: !SH_FILE! echo. wsl.exe bash !SH_FILE! set EXIT_CODE!ERRORLEVEL! echo. echo 退出码: !EXIT_CODE! pause exit /b !EXIT_CODE!这里有个细节for /f delims里的delims表示不做分隔符拆分整行输出都存进变量。因为路径里可能带空格如果省略这个参数空格后面的部分会被拆掉变量就残缺了。拖拽传进来的%~f1是文件的完整绝对路径%~1则是去掉引号的原始参数所以用%~f1更保险。3.2 安装和首次测试把这个文件保存为run-sh.bat放在桌面。有一个非常容易踩的坑如果你用记事本保存默认编码是 ANSI中文系统下就是 GBK这没问题但如果你在 VS Code 里顺手保存成 UTF-8 还带 BOMcmd 解析批处理时第一行会出现乱码脚本直接报错。建议就用记事本另存为 ANSI 编码或者把脚本里的中文提示改成英文省心很多。然后写一个测试脚本test.sh#!/bin/bash echo hello from wsl pwd把test.sh拖到run-sh.bat上松手。正常情况下会先弹出一个 cmd 窗口显示正在执行然后脚本输出hello from wsl最后窗口停住等你按任意键。如果看到这些说明整条链路已经通了。3.3 多发行版时怎么处理如果你装了多个 WSL 发行版需要在批处理里固定一个。在脚本开头加一句set DISTRO-d Ubuntu-24.04然后所有调用都写成wsl.exe %DISTRO% ...。当DISTRO为空时wsl.exe bash中间多个空格不影响解析所以这个变量可以安心留空。4. 进阶版一次补齐 CRLF、权限、目录、退出码四个坑4.1 CRLF 换行符问题Windows 上用记事本、VS Code 等编辑器创建的.sh文件默认换行符是\r\n而 Linux 只认\n。bash 在解析时会把每行末尾的\r当成命令的一部分常见的报错是$command\r: command not found或者莫名其妙的语法错误。处理方式很多我推荐在拖拽运行器里顺手用sed修正wsl.exe %DISTRO% --cd !SH_DIR! sed -i s/\r$// !SH_FILE!这条命令会把文件里的 CRLF 原地改成 LF。好处是一劳永逸脚本在 Windows 侧打开还是正常的因为现代编辑器大多自动识别但在 WSL 侧运行就再也不会遇到\r问题。有个例外要注意如果脚本处于只读状态sed -i会失败此时可以改用管道方式执行wsl.exe %DISTRO% --cd !SH_DIR! bash -c tr -d \r !SH_FILE! | bash这个写法不修改原文件但缺点也很明显脚本的标准输入被接到了管道上如果脚本里用了read等待用户输入行为会异常。所以默认方案还是sed -i修正管道方式作为兜底。4.2 可执行权限与调用方式从 Windows 拖进 WSL 的脚本一般情况下没有可执行权限。你直接运行./script.sh会遇到Permission denied。用bash script.sh就能完全绕开执行权限和 shebang 的问题——bash 会把脚本当文本逐行解释不检查执行位。所以进阶版里我一律用bash调用而不是./。4.3 工作目录为什么要单独指定默认情况下wsl.exe bash script.sh的工作目录是当前用户的家目录比如/home/me而不是脚本所在的目录。如果脚本内部用了相对路径比如cp config.txt backup/它会在家目录里找config.txt结果找不到报错方向完全错误。解决方案是用wsl.exe --cd 脚本所在目录指定工作目录。--cd参数从 Windows 10 1903 之后一直可用遇到旧版本再考虑在脚本里cd。批处理里拿到的是%~dp1也就是拖拽文件的盘符加路径注意它结尾带一个反斜杠比如D:\project\翻译成 WSL 路径后是/mnt/d/project/这个路径传给--cd是没问题的。4.4 完整的进阶版代码把上面几个点整合一下就是我现在日常在用的版本echo off rem 先关闭延迟变量再接收参数避免路径里的感叹号被吞 setlocal DisableDelayedExpansion set WIN_FILE%~f1 set WIN_DIR%~dp1 setlocal EnableDelayedExpansion if %WIN_FILE% ( echo 把 .sh 脚本拖到我身上运行。 pause exit /b 1 ) rem 多发行版场景改成实际名字例如 set DISTRO-d Ubuntu-24.04 set DISTRO for /f delims %%i in (wsl.exe %DISTRO% wslpath -a !WIN_FILE!) do set SH_FILE%%i for /f delims %%i in (wsl.exe %DISTRO% wslpath -a !WIN_DIR!) do set SH_DIR%%i if not defined SH_FILE ( echo 路径转换失败请确认 WSL 可用。 pause exit /b 1 ) echo 脚本: !SH_FILE! echo 目录: !SH_DIR! echo. rem 1. 修正 CRLF避免 Windows 编辑器引入的 \r 引发语法错误 wsl.exe %DISTRO% --cd !SH_DIR! sed -i s/\r$// !SH_FILE! 2nul rem 2. 在脚本所在目录执行这样相对路径不会乱 wsl.exe %DISTRO% --cd !SH_DIR! bash !SH_FILE! set RUN_EXIT!ERRORLEVEL! echo. echo 退出码: !RUN_EXIT! pause exit /b !RUN_EXIT!先说一个代码细节开头DisableDelayedExpansion接收参数再切换成EnableDelayedExpansion。这是为了处理路径里含!的极端情况。如果路径里有!而延迟展开一开始就是开启的赋值的一瞬间!会被当成变量引用标记吞掉。对 99% 的用户来说不影响但既然写工具尽量稳一点没坏处。还有退出码的传递。wsl.exe默认会把 Linux 命令的退出码原样返回%ERRORLEVEL%能拿到。我在批处理最后exit /b !RUN_EXIT!这样如果你把运行器放进其他批处理或计划任务里脚本的真实失败状态不会被吞掉。5. 实测踩坑记录与边界情况处理5.1 空格和中文路径我专门把脚本放到C:\Users\My Documents\工作 脚本\部署脚本.sh这种路径下测试。中文系统里只要 bat 存成 ANSI 编码路径一路传下去都没有问题。空格也没问题因为代码里所有引用点都加了英文双引号。真正容易翻车的是保存 bat 时用了 UTF-8 编码中文提示和中文路径都会在 cmd 里变成乱码进而导致 wsl.exe 收到的路径也是错的。这是整个工具最容易出问题的环节没有之一。5.2 网络盘和无法访问的挂载点拖一个网络共享盘上的脚本比如\\server\share\test.sh会失败因为 WSL 只会挂载本地磁盘wslpath拿到网络路径会报错。WSL 的配置文件里如果没挂载某个盘也会出现类似情况。我的处理原则先把脚本拷到本地再拖进去。这不算缺陷因为拖拽运行本来就是给本地高频操作用的。5.3 一个目录里多个 .sh 文件批量跑有时候你想把一个目录下多个.sh文件一次性拖进去依次执行。Windows 的拖拽会把多个路径依次传给批处理的%1 %2 %3...但批处理默认只处理%1。可以用shift做一个循环echo off setlocal EnableDelayedExpansion if %~1 ( echo 把 .sh 脚本拖到我身上。 pause exit /b 1 ) :main_loop if %~1 goto :done call :run_one %~f1 %~dp1 shift goto :main_loop :done echo 全部执行完毕。 pause exit /b 0 :run_one setlocal set WIN_FILE%~1 set WIN_DIR%~2 for /f delims %%i in (wsl.exe wslpath -a !WIN_FILE!) do set SH_FILE%%i for /f delims %%i in (wsl.exe wslpath -a !WIN_DIR!) do set SH_DIR%%i echo 执行: !SH_FILE! wsl.exe --cd !SH_DIR! bash !SH_FILE! endlocal exit /b 0这里用了call :run_one配合shift每次处理一个文件。实测下来只要不是一次拖上百个文件窗口响应都很正常。注意setlocal和endlocal要配对否则变量会越积越多。5.4 脚本需要交互输入时脚本里有read -p 请选择: choice这类交互逻辑拖拽运行器也能正常工作因为wsl.exe默认继承了 cmd 窗口的标准输入。也就是说反馈窗口里该打字打字、该回车回车不会出现任何地方都点不了的僵局。我最开始担心过这个问题实际验证过没问题。5.5 拖进去的不是 .sh 文件如果你手滑拖了一个.txt或者文件夹进去bash 会试图把它当脚本执行通常报cant open之类的错。如果想在入口处拦截可以在开头的判断里加一句if /I not %~x1.sh ( echo 只支持 .sh 脚本。 pause exit /b 1 )%~x1取的是扩展名/I忽略大小写。如果你日常也会写.bash后缀的脚本自己加个or判断即可。6. 从运行脚本到处理文件三种好用扩展6.1 把任意文件拖给固定脚本脚本拖脚本只是最基础的一层。更常见的是你有一个固定脚本需要把各种文件拖进去作为参数处理比如一个压缩脚本pack.sh想拖一个文件夹或文件进去让它打包。这时候可以做一个专门的 batecho off setlocal EnableDelayedExpansion if %~1 ( echo 把文件拖到我身上。 pause exit /b 1 ) for /f delims %%i in (wsl.exe wslpath -a %~f1) do set TARGET%%i echo 处理对象: !TARGET! wsl.exe --cd /mnt/d/tools bash /mnt/d/tools/pack.sh !TARGET! pause本质上就是把拖进来的文件翻译成路径后作为参数传给固定脚本。我给同事做过一个截图压缩工具就是这个思路。6.2 给脚本加一个参数输入框拖拽没法直接输入参数但可以弹一行提示。在进阶版代码里、执行之前插一段set /p EXTRA_ARGS请输入额外参数直接回车跳过: if defined EXTRA_ARGS ( wsl.exe %DISTRO% --cd !SH_DIR! bash !SH_FILE! !EXTRA_ARGS! ) else ( wsl.exe %DISTRO% --cd !SH_DIR! bash !SH_FILE! )参数里有空格时用户输入时自己加引号即可。这样一个工具就能覆盖固定参数脚本和临时传参脚本两类用法。6.3 注册成右键菜单用 WSL 运行拖拽之外还可以用注册表把用 WSL 运行加进文件的右键菜单。新建一个.reg文件内容如下Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Classes\*\shell\WSLRun] 用 WSL 运行 [HKEY_CURRENT_USER\Software\Classes\*\shell\WSLRun\command] \C:\\tools\\run-sh.bat\ \%1\把C:\tools\run-sh.bat换成你实际的 bat 路径双击导入然后重启一下资源管理器。右键任何.sh文件就能直接选用 WSL 运行。写在HKEY_CURRENT_USER下不需要管理员权限也不影响其他用户。这个方案的缺点是菜单项对每个文件都生效所以我自己还是更习惯桌面拖拽右键菜单主要给低频场景用。最后分享一个我在实际使用中总结的小经验拖拽运行器这类工具最忌讳一开始就追求功能齐全。先跑通最简单的通路确认 wslpath 翻译、bash 执行、cmd 回显都正常再逐步加 CRLF 修正、目录切换、多文件批量。每一步都单独验证出问题的时候范围就很清晰。我自己第一次写这个工具就是急着把所有功能堆上去结果 CRLF 和权限问题混在一起排查了半天才发现是保存编码惹的祸。希望这篇文章能让你少走这段弯路。