Bug: dsh 在 wsl2 环境下无法唤起 windows 程序

[zhaoweny]

Debug happened locally, with help of DeepSeek v4 flash; verified with ChatGPT; posted by hand
proposed title: WSL: Invoke-Item fails to open \wsl.localhost files while explorer.exe works

问题描述

DSH 运行在 WSL2 中时，通过 host.openPath / host.openTextFile 打开位于 WSL Linux 文件系统中的文件会失败。

不限文件类型，.md、.txt 等均可复现。

当前调用链大致为：

openWslPath
-> wslpath -w
-> openWindowsPath
-> powershell.exe
-> Invoke-Item -LiteralPath "\wsl.localhost<distro>..."

最终返回：

path open failed
Invoke-Item : Element not found
CategoryInfo : NotSpecified: (:) [Invoke-Item], Win32Exception
FullyQualifiedErrorId : System.ComponentModel.Win32Exception,Microsoft.PowerShell.Commands.InvokeItemCommand

与已有 WSL / PATH 问题的区别

我的 WSL 配置中设置了：

appendWindowsPath=false

但本机通过一个受控的 local shim 显式提供了 powershell.exe，因此 powershell.exe 可以正常解析并启动。

所以这与类似 spawn powershell.exe ENOENT 的问题不同：失败发生在 PowerShell 已成功启动之后。

已确认的现象

wslpath -w 生成的 Windows 路径本身有效，例如：

\wsl.localhost<distro>\home...\foo.md

对同一路径：

• Test-Path：成功
• Get-Item：成功
• Invoke-Item -LiteralPath：失败，返回 ELEMENT_NOT_FOUND
• legacy \wsl$...：表现相同
• 普通盘符路径：Invoke-Item 正常
• explorer.exe ""：成功打开默认关联程序，并正确显示文件

我也测试了：

cmd /c start
rundll32 url.dll,FileProtocolHandler
file:// URL

均无法解决此问题。

因此看起来并不是 WSL 文件路径不可访问，而是 Invoke-Item 所走的 Windows shell open 路径无法正确处理该 WSL UNC namespace。

一个可工作的修复方向

对 WSL 路径，在 wslpath -w 后不要再进入 PowerShell Invoke-Item，而是直接交给 Explorer：

await run(explorerPath, [windowsPath], signal);

即：

Linux path
-> wslpath -w
-> \wsl.localhost<distro>...
-> explorer.exe
-> Windows 默认关联程序

建议仅修改 openWslPath 的行为，保留普通 Windows 路径现有的 Invoke-Item 实现。

另一个小点是，不建议依赖 bare explorer.exe 一定存在于 WSL $PATH 中，因为 appendWindowsPath=false 是合法配置。可以显式解析 Windows Explorer 的位置，或采用其他不依赖 Windows PATH 注入的方式。

现有 internals.run seam 应该也比较方便加入 regression test，验证 WSL opener 最终调用的 executable 和 argv。

Caveat

通过 explorer.exe handoff 后，Explorer 很快返回，并且某些后续打开失败不会反馈给调用方。

对于“使用默认应用打开”这种桌面 gesture，我认为可以接受把成功语义定义为：

已成功将打开请求交给 host desktop，而不是保证目标应用最终成功渲染文件。

⸻

English summary

This appears to be distinct from the existing powershell.exe discovery / appendWindowsPath=false issue.

In my environment, appendWindowsPath=false is enabled, but powershell.exe is deliberately exposed through a local shim and launches successfully. The failure happens afterwards.

wslpath -w produces a valid \wsl.localhost<distro>... path. Test-Path and Get-Item succeed on it, while Invoke-Item -LiteralPath fails with ELEMENT_NOT_FOUND. The same path works when passed directly to explorer.exe, which launches the associated Windows application and opens the file correctly.

A possible fix is therefore to special-case WSL paths:

openWslPath
-> wslpath -w
-> explorer.exe

while leaving the native Windows Invoke-Item opener unchanged.

It would also be preferable not to assume that Windows executables are globally present in the WSL $PATH, since appendWindowsPath=false is a valid configuration.

[argszero]

已对照 master d347e70390 源级核实——你的定位准确，这属于 Windows/WSL 平台域里的一个新机制（与 appendWindowsPath=false / spawn ENOENT 类问题无关，你已正确区分）。

源码锚点（packages/util/native-command/src/path-opener.ts）：

• openWindowsPath（:102-108）：powershell.exe -NoProfile -Command "Invoke-Item -LiteralPath <path>"——所有 Windows 路径统一走 PowerShell。
• openWslPath（:111-117）：wslpath -w → 转交 openWindowsPath；WSL 判定在 :129 + isWsl（:95-99，认 WSL_DISTRO_NAME/WSL_INTEROP/内核 release），分派在 :144-151。
• 也就是说 \\wsl.localhost\... 的打开动作确实落在 Invoke-Item 上。你的实证矩阵（Test-Path/Get-Item 通过、Invoke-Item ELEMENT_NOT_FOUND、explorer.exe 成功、cmd start/rundll32/file:// 均失败）指向 PowerShell 的 shell-open 路径无法解析 WSL UNC 命名空间，而 Explorer 拥有该命名空间扩展——与源码形态一致。

explorer.exe 替换方向有三个实现坑（直接照搬 run(explorerPath, [windowsPath], signal) 会踩）：

1. 退出码：runNativeCommand（runner.ts）对 execFile 的任何非零退出都 reject；而 explorer.exe 从非交互进程拉起时常见行为是立即以 exit 1 退出（把请求转发给已在运行的 Explorer 实例后启动器随即退出）——成功也会被当成失败。实现须对 explorer 特判：detached 拉起 + 不等待退出码，或把 exit 1 视为成功（这是该二进制众所周知的怪癖）。
2. 异步无信号：explorer.exe 是 fire-and-forget，没有可靠的"打开失败"返回（与 Linux xdg-open 同构，可接受），但调用方失去失败信号这一点要在注释/行为变更里写明。
3. 不要回归普通路径：盘符路径的 Invoke-Item 是好的（你也验证了），建议按前缀分派——wslpath -w 输出以 \\wsl.localhost\ 或 \\wsl$\ 开头才走 explorer，其余保持现状；比"先 Invoke-Item 失败再退 explorer"更干净（后者会把 PowerShell 启动延迟叠加进每次 WSL 打开，且失败信号不可靠时难以判定）。

另注意 openNativeTextFile 在 WSL 下也走同一路径：explorer 会用默认关联打开文本文件，与现状 Invoke-Item 行为一致（text-editor 偏好本就是 macOS-only 的 open -t）。

修复面在 native-command（host 原语，非插件可挂载层）→ upstream-fix 候选；你的 patch 方向正确，把 explorer 退出码坑一并纳入即可直接提交讨论区供维护者拾取。