Launching windows commandline commands within a WSL, what's the story?

Question

In this Superuser question, I'm looking for a way to make the following work:

find DLL.dll -exec /mnt/c/.../Windows_command {} \;

Yes, I'm indeed trying to launch a Windows command inside a WSL.
To my surprise, this has worked before, but now it's not anymore (hence the Superuser question), the corresponding bounty explains how much I'd like this to work 😊

Here I would like to talk about the background of this whole thing: I always thought of WSL as being a real "Linux"-emulator on a Windows machine, which was capable of launching UNIX commands on files on a Windows computer, nothing more, but apparently there is more:

The following WSL command is working:

/mnt/c/Windows/System32/winver.exe

(As most of you might know, winver is a command, used to know the Windows version of a computer)
Not only does it "work", it also launches exactly the same Windows dialogbox as if the command was launched from Windows commandline.

The following Windows command is working:

C:\Development\util>sigcheck.exe C:\...\abseil_dll.dll

From inside the directory of the abseil_dll.dll file, the following WSL command is also working:

/mnt/c/Development/util/sigcheck.exe abseil_dll.dll

However, the following WSL command is not working:

/mnt/c/Development/util/sigcheck.exe /mnt/c/.../abseil_dll.dll

It looks as if Windows commandline commands can be launched from within a WSL environment, but they can't handle the WSL directory structure.

I've heard that this might be due to a "mounting configuration": if the result of mount | grep "/mnt/c" mentions drvfs, it would work, but as it mentions 9p, this "explains" why it doesn't.

Some surfing tells me that before, WSL mounting was done according to drvfs, which "allowed" so-called interoperability, while now it's done according to 9p, which does not allow this?
This would mean such a serious degradation of WSL features, I can't imagine this to be true.
There also seems to be the possibility to configure the WSL, where the [interop] chapter, described here, might be useful.
... unfortunately this seems not to be true, as you can see from the following /etc/wsl.conf excerpt (WSL command):

cat /etc/wsl.conf ... [interop] enabled = true appendWindowsPath = true

Can anyone shed some light on this matter?
Thanks in advance

Does it help if you use wslpath? /mnt/c/Development/util/sigcheck.exe $(wslpath -w /mnt/c/.../abseil_dll.dll) — Stephen Kitt
– Stephen Kitt, Commented Dec 1 at 8:48
@StephenKitt: that might be useful, but this means I need to change the find command, and I'd like to keep that as it was working before. — Dominique
– Dominique, Commented Dec 1 at 10:07

Dominique · Accepted Answer · 2025-12-01 15:54:11Z

I've found the solution, based on the following observation:

<command> /<directory>/file

=> this does not work.

cd /<directory> <command> file

=> this does work.

In other words: I need to make sure that I launch the command from inside the directory where the file resides.
My first idea was to look for some find -exec parameter, which would solve the problem, but there is another one:

find -execdir

Indeed: replacing -exec by -execdir solves my problem.

Many thanks to all people who has helped me in this big search!

You could probably wrap the path in wslpath to convert it to a Windows path. — Bob
– Bob, Commented Dec 2 at 12:38
Using wslpath is indeed a proposal which has been made before, but the change on my command is too large. Simple replacing -exec by -execdir does the trick too and is far simpler. — Dominique
– Dominique, Commented Dec 2 at 15:06

ntninja · Accepted Answer · 2025-12-01 21:11:32Z

You are confused by WSL1 vs WSL2, I think.

WSL1 was indeed a Linux emulator built into the Windows NT kernel as driver, this allowed it to transparently map native DOS path, among other things, giving very deep integration.

WSL2 on the other hand launches a customized native Linux kernel as a kind of MicroVM and then uses various Linux drivers to talk to the Windows host kernel instead.

This is also why the difference between “drvfs” (which was a pseudo-filesystem that the WSL1 system used to explain to Linux application why there are Windows-y things floating around) and “9p” which is a network filesystem that the Linux kernel is told on startup to connect to, where the Windows kernel (or maybe also outside the kernel, that’s just an implementation detail here) exposes the outside Windows filesystem hierarchy to the best of its abilities to the an unaware Linux kernel.

They probably could have hacked the Linux filesystem handling to make native Windows paths work in WSL2, but it doesn’t fall naturally out of the used architecture as it did with WSL1, so they apparently decided it wasn’t worth it since you can still use the /mnt mount point to access the Windows host paths.

There is no way to reinstate this ability from your end, unless your willing to the necessary Linux kernel hacking yourself.

However, the following might be “close enough”:

for drive in {a..z}; do ln -s "/mnt/${drive}" "${drive^^}:" done

… this will just create symbolic links for A: through Z: in the current directory, allowing for look-alike paths from the Linux side as long as you don’t change the current working directory.

Although it looks tempting, there still is the issue with the UNIX slashes and Windows backslashes: in UNIX (WSL) I'm talking about the directory /mnt/c/Temp_Folder/ (mind the forwardslashes) while in Windows I'm talking about the same directory as `C:\Temp_Folder` (mind the backslashes). — Dominique
– Dominique, Commented Dec 2 at 7:34
Use wslpath to correctly do the conversion. Avoid hacky assumptions. — Bob
– Bob, Commented Dec 2 at 12:40
Do you know if there is a good writeup somewhere why they chose the different strategies between WSL1 and WSL2? — Polygnome
– Polygnome, Commented Dec 3 at 11:27
@Polygnome The MS commandline blog is a good place to start, and the WSL 2 announcement post has most of it. Short answer is better kernel compat, better filesystem support, faster update cadence. More recently, GPU support. — Bob
– Bob, Commented Dec 3 at 15:45
@Dominique: Yes, as I said ‘might be “good enough”’. Definitely not perfect, no. Many Windows programs do swallow forward slashes though, so it is something at least… Otherwise, you’ll need to pass every path through ~~winepath~~ wslpath instead as @Bob said, yes. — ntninja
– ntninja, Commented Dec 4 at 1:22

povlhp · Accepted Answer · 2025-12-02 20:39:16Z

Can't you just run it inside a CMD:

/mnt/c/Windows/System32/cmd.exe /c "C:\Windows\system32\notepad.exe"

If you want to use the path from find, you need to convert to a windows path. But not everything in WSL is reachable using Windows.

It is trivial to use sed to fix the path - replace start in make / into
But depends on mount points.

As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. — Community
– Community Bot, Commented Dec 1 at 17:10

Stack Exchange Network

Launching windows commandline commands within a WSL, what's the story?

3 Answers 3

You must log in to answer this question.

Hot Network Questions

Launching windows commandline commands within a WSL, what's the story?

3 Answers 3

You must log in to answer this question.

Related

Hot Network Questions