Note: Also be sure to read the follow-up to this post that covers a subsequent improvement in that you no longer have to specify the absolute path to Windows executables if they exist on your path! Content below updated to reflect this change! Windows 10 Insider build #14951 has just landed and includes a very exciting new feature that we know you’re going to love: Bash <--> Windows Interop!

Many of you have been asking for this capability for quite a while, and now it’s finally here! Starting with build #14951, you can:

• Call Windows executables from within Bash
• Invoke Linux binaries and capture output from Windows

Let’s take a closer look at these scenarios:

Call Windows executables from within Bash

From within a Bash/WSL console can invoke Windows executables by specifying the (correctly-cased) name of the executable, including its .exe extension:

$ notepad.exe [filename]

This will launch the Notepad text editor (opening the requested file if specified):

Notice that in the example above, we didn’t have to specify the full path to notepad.exe: That is because when Bash is launched, the Windows path is appended to the Linux path, so you can invoke any .exe that exists on your Windows path by simply typing its (correctly-cased) name and .exe extension!

If you want to invoke an .exe that is not on your path, specify the full path to the exe itself:

You can also create aliases to commonly used tools if you wish:

So what can you do with this new-found capability to invoke Windows executables from within Bash? Common scenarios include:

• Invoke build tools like MSBuild to automate your build/CI system/processes (see above)
• Launch Windows tools & IDE’s like Notepad, Visual Studio / VSCode / Sublime / Notepad++ / etc. to edit files & projects
• Execute .bat/.cmd scripts by calling cmd.exe /C ... :

Note: If you try to launch a Windows tool, asking it to open a file that is located in your Linux filesystem, it will be unable to open the file (it will appear to be “missing”) and Bash will inform you of this problem stating that it was : “Unable to translate current working directory. Using C:\WINDOWS\system32”. This is due to a current limitation in WSL wherein Windows apps should NOT be used to open files in the Linux filesystem. Opening files in the Windows filesystem is fully supported using both Windows apps and Bash/Linux tools (via /mnt//…), but avoid opening Linux files using Windows apps at all cost!

Capturing Bash output from Windows

As useful as it is to invoke Windows executables from within Bash, it’s also incredibly useful to invoke Linux applications and tools from Windows, and capture and process their output in Windows apps.

In the example below, we’ll call bash.exe -c ... to return a list the default Linux user’s root folder and see how many sub folders contain the string “sr” using PowerShell’s select-string cmdlet:

To learn more about how Bash <--> Windows interop works, be sure to read and/or watch the accompanying blog and video where Ben Hillis takes Seth Juarez on a tour of this amazing new feature’s internal workings!

Stay tuned for more Windows 10 command-line coolness in the coming weeks 😉

Rich, on behalf of the Bash/WSL and Console teams.