把 Windows 里的 .sh 脚本拖到 WSL 里运行听起来就是个“拖一下、跑一下”的小事但真正操作起来你会发现处处是坑资源管理器拖过去的 Windows 路径 bash 根本认不出来用记事本写的脚本一执行就报$\r脚本里明明有输出窗口却一闪而过……这篇文章我会直接把“Windows 拖拽运行 WSL SH 脚本”这条链路彻底打通从 WSL 环境配置、拖拽中转方案到脚本编码、路径转换、权限设置全部走一遍每一步都是我在实际环境里跑过、踩过坑之后沉淀下来的做法适合所有想把 Windows 和 WSL 工作流串起来的人。1. 场景与核心思路拆解1.1 谁会需要“拖拽运行”这个能力先说说这个需求的真实场景。我平时维护一批 Linux 脚本比如日志归档、数据库备份、JAR 包启动辅助脚本这些脚本在服务器上跑得好好的但开发环境在 Windows 上经常要临时改一下参数、在本地测试一下逻辑。每次都打开 WSL 终端手动 cd 到目录、再敲bash xxx.sh虽然也就几秒钟但次数多了非常烦尤其是脚本路径很深、名字又长的时候敲错一个字母就是一条报错。还有一种情况是团队协作。同事用 U 盘或者微信发来一个.sh文件你只想快速看一眼它在本地能不能跑、输出什么结果不想为了一个临时脚本去记路径、敲命令。这时候如果能把文件直接拖到某个图标上、或者右键一下就能用 WSL 执行体验会舒服很多也减少出错概率。这个需求本质上不是一个“必须用拖拽”的需求而是一个“减少中间步骤”的效率需求。拖拽只是交互方式真正难的是两套系统的衔接Windows 的路径体系是C:\Users\...WSL 里是/mnt/c/Users/...中间差着一层转换另外 Windows 编辑器和 Linux 解释器对文件格式的理解也不同换行符、编码、执行权限这些细节都会冒出来。1.2 为什么不能直接把脚本拖进终端很多人第一次尝试都是把.sh文件从资源管理器拖到已经打开的 WSL 终端窗口里结果发现终端里插进来的不是文件内容而是一段路径文本比如C:\Users\me\Desktop\test.sh。bash 拿到这个东西会怎么处理它不认识反斜杠大概率会把它当成一个带引号的字符串然后报No such file or directory。有人会说那我把反斜杠改成斜杠不就行了C:/Users/me/Desktop/test.sh这个路径在 WSL 里还是不对因为 WSL 访问 Windows 磁盘需要经过挂载点也就是/mnt/c/Users/me/Desktop/test.sh。这一步是必须的不是简单替换分隔符能解决的。Windows Terminal 倒是支持把文件拖进去自动转成 WSL 能用的路径格式但一是版本要求比较高二是它转换出来的路径有时候带着奇怪的前缀三是并不是所有人都用 Windows Terminal很多老用户还是习惯用传统的bash.exe或者 CMD 窗口。所以最稳妥的思路不是指望终端自动转换而是我们自己写一个“中转层”让拖拽这个动作由 Windows 程序接收然后由它调用wslpath做路径转换再交给 WSL 里的 bash 执行。2. 先把 WSL 环境调试到顺手状态2.1 安装与基础配置如果你还没装好 WSL这一步必须先补齐。Windows 10 较新版本和 Windows 11 都支持 WSL 2安装命令很简单用管理员权限打开 PowerShell 或者 CMD执行wsl --install -d ubuntu-24.04wsl --install会自动启用需要的 Windows 功能包括虚拟机平台然后下载并安装你指定的 Ubuntu 发行版。首次启动会让你创建 Linux 用户和密码这个记住别忘后面对很多配置都有用。装完之后建议顺手执行一下wsl --update把 WSL 内核更新到最新版本有些拖拽方案在旧内核上表现不稳定。安装过程中有几个容易卡住的地方如果提示需要启用虚拟机监控程序需要去 BIOS 里打开虚拟化如果wsl --update下载特别慢可以多等一会儿或者换个网络环境。这些我在后面第 5 章会详细说这里先保证基础环境能跑就行。检查当前 WSL 状态可以用wsl --status wsl -l -v-l -v会列出你安装的所有发行版以及它们的 WSL 版本。我建议统一用 WSL 2因为 WSL 1 对路径挂载和文件系统的处理方式不同部分脚本行为会有差异。2.2 关键配置默认用户与 metadata 挂载装好 WSL 只是第一步要让它和 Windows 文件“友好相处”还需要改两个配置都在 WSL 内部的/etc/wsl.conf文件里。默认情况下从资源管理器拖拽文件进入 WSL 时可能会以 root 身份或者错误用户身份操作造成权限混乱。我们可以在 wsl.conf 里指定默认用户[user] default你的用户名另一个更重要的配置是 metadata 挂载选项。WSL 挂载 Windows 磁盘也就是/mnt/c时默认不保存 Linux 的文件权限信息所以你在 Windows 里新建的test.sh到 WSL 里看ls -l会发现没有执行权限x甚至chmod x也不生效实际上是生效了但马上被忽略。要解决这个问题在 wsl.conf 里加上[automount] enabledtrue optionsmetadata,umask22,fmask11metadata让 WSL 在 Windows 文件系统上模拟记录 Linux 权限位umask22、fmask11的意思是给目录和文件一个默认权限文件是 644、目录是 755这样普通脚本至少具备读权限自己创建的脚本也更容易变成可执行。改完配置后在 PowerShell 里执行wsl --shutdown然后重新进入 WSL 才生效。这几行配置是整个拖拽方案能否省心的基础尤其是metadata很多人脚本报Permission denied都是因为它没开。2.3 确认 bash 与 wslpath 可用在 WSL 里执行which bash which wslpathbash用来解释执行脚本wslpath用来做 Windows 路径和 Linux 路径互转这两个工具是整个拖拽方案的两个齿轮。正常情况下 Ubuntu 默认自带wslpath位置在/usr/bin/wslpath不需要额外安装。可以在 WSL 里简单验证一下转换效果wslpath -a C:\Users\me\Desktop\test.sh输出应该是/mnt/c/Users/me/Desktop/test.sh说明路径链路是通的。后面我们会把这条命令封装到 Windows 的批处理文件里实现自动化转换所以这一步先确认没问题。3. 三种可落地的拖拽方案3.1 方案一用批处理中转拖到 bat 上运行这是我最推荐的方式也是我现在日常在用的方案。原理很简单写一个run-wsl-sh.bat放在固定目录比如C:\tools以后需要运行某个.sh文件时直接把它从资源管理器拖到这个 bat 文件上松手脚本就会被自动执行。先看完整代码echo off setlocal EnableDelayedExpansion if %~1 ( echo 请将一个 .sh 脚本拖到本文件上运行。 pause exit /b 1 ) if /i not %~x1.sh ( echo 只支持 .sh 脚本当前文件%~nx1 pause exit /b 1 ) set WIN_PATH%~s1 for /f delims %%i in (wsl wslpath -a !WIN_PATH!) do set LINUX_PATH%%i echo 准备执行: !LINUX_PATH! echo. wsl -e bash -lc bash !LINUX_PATH! echo. pause几个关键点我拆开讲。%~1是 bat 接收到的拖拽文件路径%~s1是它的短路径8.3 格式。为什么要用短路径因为 Windows 路径里经常出现空格、中文、符号这些在 cmd 里都是“危险字符”短路径可以最大限度地避免解析错乱。代价是短路径可读性差比如C:\Users\ADMINI~1\Desktop\test.sh看着不舒服但wslpath完全能处理。for /f delims %%i in (wsl wslpath -a !WIN_PATH!) do ...这行是核心它调用 WSL 里的wslpath把 Windows 路径转换成 Linux 路径并把结果存到LINUX_PATH变量里。wsl -e bash -lc bash !LINUX_PATH!表示用 WSL 的 bash 启动一个登录 shell然后在里面执行bash /mnt/c/.../test.sh。这里用bash xxx.sh而不是./xxx.sh是有讲究的/mnt/c下的文件默认没有执行权限用bash作为解释器可以绕过执行位问题脚本本身也不需要chmod x。最后pause一定不能省否则脚本执行完窗口直接关闭你有任何输出都来不及看只会看到一个黑框一闪而过。这个方案的优点是零依赖不需要安装任何额外软件bat文件可以用记事本直接建复制代码保存即可。缺点是它只能通过“拖到图标上”这种交互方式使用如果你的手离鼠标比较远可能还是觉得不够快。3.2 方案二注册右键菜单一键用 WSL 运行如果你更习惯右键操作可以把方案一的 bat 注册到 Windows 右键菜单里。这样任何文件上点右键都能看到“用 WSL Bash 运行”这个选项点一下就执行不需要拖拽。先把run-wsl-sh.bat放到一个稳定路径比如C:\tools\run-wsl-sh.bat。然后新建一个文本文件把下面内容粘贴进去保存为add-rightmenu.regWindows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shell\WSL-Bash] 用 WSL Bash 运行此脚本 IconC:\\Windows\\System32\\bash.exe [HKEY_CLASSES_ROOT\*\shell\WSL-Bash\command] \C:\\tools\\run-wsl-sh.bat\ \%1\注意Icon和最后一行里的路径都要改成你机器上的实际路径反斜杠要写成双反斜杠注册表转义规则。双击 reg 文件导入提示确认就点是。之后随便找个.sh文件测试右键里应该就多了一个“用 WSL Bash 运行此脚本”。这个方案的体验比拖拽更顺尤其是你的脚本放在很深的多级目录里时根本不用一层层找到 bat 文件再拖直接原地右键就行。而且注册表方案其实不限制扩展名你可以在 bat 里通过%~x1判断类型只允许.sh这样误操作其他文件时不会真的拿去执行。想取消右键菜单时把同样内容的注册表保存成 delete 版本项名改成带-前缀或者在注册表编辑器里直接删掉HKEY_CLASSES_ROOT\*\shell\WSL-Bash这个项即可不影响其他配置。3.3 方案三调试期用的拖拽方式与适用场景前两种方案适合“稳定使用”但如果你只是临时调一个脚本或者正在开发阶段、脚本会频繁改动我建议换一个思路直接用 WSL 里的bash -c $(wslpath ...)手动组合命令或者干脆把脚本放到 WSL 家目录里再运行。具体操作是这样的在 WSL 终端里用一个自动补全技巧——先输入bash然后把 Windows 资源管理器里的文件拖进终端。Windows Terminal 在某些版本下会自动把路径转成/mnt/c/...格式再配合你的 WSL 用户目录就是 Linux 路径实际能否成功取决于终端版本和设置不要完全依赖。更稳定的是自己手动转bash $(wslpath -a /mnt/c/Users/me/Desktop/test.sh)这种方式适合某个脚本只需要跑一两次不值得为它配置全局右键菜单或拖拽中转的场景。调试的时候脚本放在 Windows 桌面改完直接复制一条转换命令执行也不会把桌面搞乱。真正需要稳定、高频使用的时候方案一和方案二才是正道。我自己的习惯是一套右键菜单常驻bat 也固定在任务栏或者桌面角落两边都能用看当下哪个顺手。3.4 方案对比速查方案交互方式适合场景配置复杂度稳定性bat 中转拖拽拖到 bat 图标日常高频、脚本路径固定低一个 bat 文件高注册表右键菜单任意文件右键脚本分散、多目录使用中需要导入 reg高终端内路径转换手动粘贴命令临时调试、一次性运行无额外配置中实际体验下来右键菜单的方案最省鼠标操作拖拽方案胜在配置最少、原理透明、好排查问题。没有谁绝对更好两个都配上也并不冲突反正核心工具类逻辑都在那个 bat 里改一处所有入口都能生效。4. 脚本本身的四个关键坑4.1 换行符CRLF问题很多 Windows 用户写脚本喜欢用自带记事本或者 VSCode默认保存时换行符是 CRLF\r\n而 Linux 下标准换行符是 LF\n。WSL 里的 bash 看到\r会把它当成一个普通字符于是在执行脚本时经常报错bash: $\r: command not found这个问题太经典了几乎每个从 Windows 切到 WSL 的人都会遇到。报错信息里的\r就是那个看不见的回车符。解决的办法有三类第一类改编辑器的保存设置。VSCode 右下角有 LF/CRLF 切换按钮点开改成 LF 再保存新版记事本也在“另存为”里可以选择换行符格式Windows 11 的记事本默认已经是 UTF-8 无 BOM 且换行符可选。只要养成本地脚本统一用 LF 的习惯这个坑就基本不会踩。第二类批量转换已有文件。老脚本已经带着 CRLF直接用sed处理sed -i s/\r$// test.sh或者安装dos2unix工具sudo apt install dos2unix dos2unix test.sh第三类在 bat 中转层里自动处理。如果你想把所有脏活都挡在外面可以在 bat 里执行脚本前先调一下sed给 bash 传一个清理后的副本。不过这属于“兜底手段”能用编辑器保持 LF 是最好。4.2 BOM 与编码问题如果脚本是 Windows 记事本保存的 UTF-8 格式可能在文件头部带有一个 BOM字节顺序标记\xEF\xBB\xBF。这个 BOM 在 Windows 下不可见但到了 Linux 里就成了脚本开头的前三个字节bash 第一行往往是指定解释器的#!/bin/bash一旦前面多出这几个字节bash 会报bash: ./test.sh: /bin/bash^M: bad interpreter: No such file or directory不管是bad interpreter还是command not found根源基本都是 BOM 或者 CRLF。处理方法是把文件另存为 UTF-8 无 BOM 格式。VSCode 里可以通过“选择编码”-“通过编码保存”-“UTF-8”实现也可以用sed去掉 BOMsed -i 1s/^\xEF\xBB\xBF// test.sh脚本里如果有中文输出还需要确认终端使用的是 UTF-8 locale。WSL 的 Ubuntu 默认通常是C.UTF-8如果你改了系统区域设置注意别把编码搞乱否则日志里中文会变成乱码。4.3 路径转换与特殊字符拖拽方案里最容易出岔子的就是路径里有空格或者特殊符号。比如C:\My Scripts\test.sh如果不做处理bash 会把它拆成C:\My和Scripts\test.sh两段肯定执行不了。我们的 bat 中转层已经用了两层保险。外层用%~s1拿到短路径内部再用双引号包裹路径变量这样空格问题基本解决。但还有一个隐藏问题如果文件路径或文件名里有单引号而我们调用的 bash 命令结构是bash 路径单引号会提前截断路径导致执行失败。单引号在 Windows 文件名里是合法字符虽然少见但不是没有。遇到这种情况建议把文件改名或者用 wslpath 转换后再手动执行。还有一类特殊字符是。在 cmd 里是命令分隔符路径里出现它会让脚本解析错乱。短路径方案能绕开这个问题因为 8.3 短名不会包含。这也是我坚持在 bat 里用%~s1的原因宁可路径丑一点也要保证执行不出错。4.4 执行权限与 metadata前面说过WSL 挂载的 Windows 磁盘默认不带执行权限所以如果你直接执行./test.sh会报Permission denied。方案一的 bat 里用的是bash 路径显式指定了解释器所以不需要执行位。但如果你希望脚本也能通过./test.sh方式运行比如脚本里有一些相对路径的依赖就需要回到第 2.2 节提到的 metadata 配置。开启 metadata 之后可以到 WSL 里对脚本chmod x /mnt/c/My\ Scripts/test.shchmod 之后再执行./test.sh就能通过。需要注意metadata 开启后不仅脚本属性会变化所有/mnt/c下的文件权限行为都会变得更像 Linux如果公司网络驱动器或者共享盘挂载在这个路径下可能带来一些权限上的“意外惊喜”建议先在自己电脑上验证没问题再推广。5. 常见问题排查与个人实操心得5.1 高频报错与症状对照症状原因解决办法窗口一闪而过bat 没有pause或脚本里执行了exit补上pause用bash -lc包裹脚本调用$\r: command not found脚本换行符是 CRLF编辑器转 LF或sed -i s/\r$//bad interpreter脚本头部带 BOM另存为 UTF-8 无 BOM或 sed 去 BOMPermission denied/mnt/c 下无执行权限用bash 路径执行或开启 metadata 后 chmodNo such file or directory路径没有用 wslpath 转换调用wslpath -a转换再执行如果你用的方案是 bat遇到任何不确定的错误先把 bat 里的wsl -e bash -lc bash !LINUX_PATH!单独放到一个普通 cmd 窗口手工执行看 WSL 端的原始输出。bat 窗口只能显示最终结果真正的排错信息还是要看 WSL 里的报错。5.2 安装与更新常见卡点wsl --install -d ubuntu-24.04执行后如果长时间卡在“正在下载”大概率是网络问题。可以尝试先执行wsl --install不带发行版参数让它安装 WSL 基础组件再单独安装发行版或者分步启用 Windows 功能dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart改完重启系统再运行wsl --update和后续步骤。wsl --update很慢时可以设置代理如果你有或者直接等待微软的更新服务偶尔不稳定但一般不会失败只是慢。如果安装的是老版本 WSL第一次启动 Ubuntu 可能提示需要更新 WSL 内核按照提示操作即可。还有一类问题开机后wsl命令找不到。这通常是 Windows 功能没启用完或者 PATH 环境变量被其他软件改动过。检查C:\Windows\System32\wsl.exe是否存在存在的话手动加到 PATH不存在就重新执行上面的 dism 命令并重启。5.3 磁盘空间无法释放的处理WSL 2 的虚拟磁盘是动态增长的Ubuntu 里删除大文件后Windows 侧的ext4.vhdx文件往往不会自动收缩于是你会看到wsl内df -h显示空间已释放但 C 盘占用一点没变。这个现象很多人问。处理方法是先彻底关闭 WSLwsl --shutdown然后以管理员身份打开 PowerShell用Optimize-VHD压缩虚拟磁盘。这个命令属于 Hyper-V 模块Windows 专业版和企业版默认可用家庭版可能需要单独开启 Hyper-V 功能。Optimize-VHD -Path $env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu24.04LTS_*\LocalState\ext4.vhdx -Mode Full路径里的发行版名要和你安装的版本一致。执行完再启动 WSL磁盘占用会明显下降。注意压缩期间不要占用大量磁盘留出足够空间给 VHDX 临时文件。5.4 实操心得的几点总结文章最后分享几个我实际使用中沉淀出来的个人习惯供你参考。第一脚本尽量统一放在 Windows 侧一个固定目录比如D:\scripts让所有拖拽、右键入口都指向同一片区域。这样wslpath转换出来的路径基本可控脚本之间的相对引用也不容易乱。如果你把脚本丢在桌面、下载、网盘同步目录各处路径来源太杂出问题的概率会明显上升。第二bat 里保留pause但是别让脚本输出被淹没。我会在 bat 里打印一行分隔线再打印执行路径最后输出脚本结果屏幕内容清晰可读。别人拿你的 bat 去用时也会觉得这个工具“有头有尾”。第三给 bat 加一个浮窗提示不是必须的但如果你经常把文件拖错可以在if /i not %~x1.sh分支里给出明确的中文提示而不是直接退出。多一行判断能让这个工具从“自己用”变成“团队里能流传”的小工具。第四遇到疑难问题先从最简单路径排查先在 WSL 里手动执行脚本看报错再跑wslpath确认路径转换最后才怀疑 bat 逻辑。顺序反了你会被一堆假象带偏。这套“Windows 拖拽运行 WSL SH 脚本”的方案我用了一年多没有出过大问题核心就是那个几十行的 bat 文件加一行 wsl.conf 配置。你可以先按方案一搭出来跑通第一个脚本再根据使用频率决定要不要加右键菜单不用一次性全配齐。真正用起来之后你会发现Windows 和 WSL 之间的这扇门其实只隔着一个路径转换和几个隐藏的换行符。