Skip to content

fix(explorer): reveal files in the Windows Explorer when the host runs under WSL - #575

Open
Kerwin75631591 wants to merge 1 commit into
omdsh-dev:mainfrom
Kerwin75631591:fix/wsl-reveal-file-explorer
Open

fix(explorer): reveal files in the Windows Explorer when the host runs under WSL#575
Kerwin75631591 wants to merge 1 commit into
omdsh-dev:mainfrom
Kerwin75631591:fix/wsl-reveal-file-explorer

Conversation

@Kerwin75631591

Copy link
Copy Markdown

fix(explorer): reveal files in the Windows Explorer when the host runs under WSL

Problem

The file-tree context menu action "Show in folder" (the built-in Explorer open-with target, kind reveal) does nothing when DSH runs inside WSL2 (e.g. dsh web hosted in Ubuntu on WSL, UI opened from the Windows browser):

  • process.platform is 'linux', so the default branch of revealCommand spawns xdg-open <parent-dir>.
  • A WSL host has no Linux desktop file manager and typically no xdg-open (spawn fails with ENOENT, which the route deliberately swallows), and even when xdg-open exists it cannot open the Windows desktop's Explorer.
  • Net effect: right-click → Show in folder silently does nothing. (The win32/darwin branches were already correct; only the Linux default branch missed the WSL case.)

Change

Detect the WSL runtime (WSL_DISTRO_NAME env or /proc/version containing microsoft) and, for reveal actions, hand the path to the Windows Explorer exactly like the win32 branch:

  1. Translate the absolute path with wslpath -w/mnt/c/... becomes C:\..., Linux-filesystem paths become \\wsl.localhost\<distro>\....
  2. Spawn explorer.exe /select,<translated> so the file/directory is selected in Explorer.
  3. When launching a .exe opener under WSL, extend the child PATH with /mnt/c/WINDOWS (+ System32) so Windows interop resolves even for hosts started with a slim PATH.

Plain-Linux and native-macOS/Windows behavior is unchanged (revealCommand still defaults to the non-WSL xdg-open branch; URL open-with targets are untouched — out of scope).

Design notes

  • The command builders stay pure/testable: wsl and the path translator are injected parameters, defaulting to non-WSL; launchExternal is the only place that consults isWslRuntime() and the real wslpath-based translator.
  • Added a unit test with an injected translator so the WSL branch is covered on non-WSL CI hosts (which have no wslpath).

Test plan

  • New unit test in tests/open-external.spec.ts covers the WSL reveal branch (injected translator).
  • Existing revealCommand linux/win32/darwin tests unchanged and still green.
  • Manual, on a real WSL2 host (Ubuntu-24.04, DSH 0.1.2 host in WSL): right-click a workspace file → Show in folder now opens Windows Explorer with the file selected (Linux-fs and /mnt/c paths both verified).

…s under WSL

The file-tree 'Show in folder' action spawns xdg-open on Linux, but a WSL
host has no Linux file manager (and usually no xdg-open), so reveal silently
did nothing. Detect WSL (WSL_DISTRO_NAME or /proc/version) and hand reveal
to explorer.exe with a wslpath -w translated /select,<path> instead, keeping
the Windows dirs on PATH for interop. Command builders stay pure (wsl flag +
translator injected); non-WSL Linux behavior unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant