How can I run a Windows executable from WSL (Ubuntu) Bash

Along with Windows 10 Anniversary update for summer 2016, came the possibility to run ubuntu binaries inside the new Windows Subsystem for Linux (WSL), a "lightweight" virtualized subsystem.

Unfortunately, launching C:\Windows\System32\bash.exe, another bash ELF binary starts a process inside the WSL, from where you cannot escape! You may launch only other ELF binaries.

So how can I execute *.exe files from Windows Bash?[1]

[1] Question asked also in Microsoft's "official" GH support repo.

In the Windows 10 Creators Update (build 1703, April 2017), this is natively supported. So you can now run Windows binaries from Linux...

notepad.exe or any other .exe (the extension is needed and it needs being on your path, some older versions need the whole path)

...and vice versa using one of the following:

• bash.exe -c command_to_run i.e: bash.exe -c ls
• bash -c command_to_run i.e: bash -c ls
• wsl command_to_run i.e: wsl "ls"; or specify the distro you want to use to run it using:
  • ubuntu run ls

For more information, see the above linked article.

Native solution

The official solution provided with Windows 10 Insider Preview Update (14951) is based on the almost forgotten binfmt_msc Linux facility for launching binaries. The registration command for the binfmt_misc would be like this (where /init is the provisional binfmt_misc "interpreter" for the win-executables):

sudo echo ":WSLInterop:M::MZ::/init:" > /proc/sys/fs/binfmt_misc/register

And then win-executable would be launched like regular programs:

$ export PATH=$PATH:/mnt/c/Windows/System32
$ notepad.exe
$ ipconfig.exe | grep IPv4 | cut -d: -f2
$ ls -la | findstr.exe foo.txt
$ cmd.exe /c dir

> Not that any win-executable must reside in the windows (DrvFs) file-system - not on the Linux's file-system (VolFs) - in order to inherit a proper Windows working-directory.

The cbwin alternative

Untill you get the latest build, project cbwin offers a workaround, by installing 3 new linux commands inside WSL:

• wcmd: call a win-executable through cmd.exe.
• wrun: call a win-executable synchronously with CreateProcess, and wait to die (not using cmd.exe).
• wstart: launch a detached (asynchronously) command (with the use of cmd.exe).

In order to use them, you must:

1. Install cbwin:
   • a new outbash.exe will be installed in your regular Windows filesystem (somewhere in your %PATH%), plus
   • the 3 linux-commands in the WSL filesystem.
2. Use this outbash.exe (wherever you installed it) to start WSL, NOT C:\Windows\System32\bash.exe!
3. Prefix any win-executables with one of those commands, e.g. wrun notepad.

Tip: If the executable launched with wcmd or wrun spawns any children, these survive only for as long that executable remains alive.

In other words, trying to start notepad.exe with wcmd won't work, because notepad will be killed just after having been launched -- Use wrun (synchronously) or wstart (asynchronously) in this case.

While running an .exe from the command line works, when running from say PHP via exec() I couldn't get that to work. Adding /init , however , does work. This is my working /usr/local/bin/convert file for GraphicsMagick installed on Windows:

#!/bin/sh
/init "$(ls /mnt/c/Program*/GraphicsMagick*/gm.exe|tail -1)" convert "$@"

why not just use

$ powershell.exe Start filename

Start is the Windows equivalent to xdg-open on most linux or open on macOS, which means "open with default desktop application". I like to alias it to open.

I'm a bit baffled by this. I added a symlink:

$ ls -l /c                                                                                               
lrwxrwxrwx 1 root root 5 Dec  3 10:24 /c -> mnt/c  

now ls /c gives the same result as ls /mnt/c

But now: /c/Program\ Files/Java/jdk1.8.0_211/bin/java.exe -version ==> nothing

However:

/mnt/c/Program\ Files/Java/jdk1.8.0_211/bin/java.exe  -version 
java version "1.8.0_211"                                                                                                Java(TM) SE Runtime Environment (build 1.8.0_211-b12)                                                                   Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode) 

The same thing happens for other windows executables. Has WSL got a bug implementing symlinks?