Interop between Windows and Bash


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
  • Capture output from Linux executables/scripts 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 full path to the executable file, along with its .exe extension:
2-AbsolutePath

To make calling Windows executables more convenient, you can add folders containing commonly used tools to your Bash path, allowing you to invoke executables within these folders by just typing the executable’s name (and .exe extension):

Adding Windows Folders to the Bash Path

Alternatively, you can create aliases to commonly used tools:

3-Alias

Notes:

  1. The team are working on providing ways to incorporate some/all of your Windows environment path into the Bash path. Stay tuned for more news on this feature in future releases
  2. When you close your last open Bash session your temporary Path changes, etc. will be lost. To make these changes available to all Bash sessions, add them to your .bashrc, e.g.:
    export PATH=$PATH:/mnt/c/Windows/System32

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
    Open Notepad from Bash
  • Execute .bat/.cmd scripts by calling cmd.exe /C ... :Cmd 'dir' from Bash

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:

Invoking Bash from PowerShell

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.


Comments (30)

  1. Diti says:

    The contributions Microsoft makes towards the open-source and Linux world is amazing! I am delighted to learn about this new feature. 🙂

    1. DaBang says:

      thats true

  2. Roman Semenov says:

    Is there a path translation when you invoke “notepad.exe foo.txt”? What happens if I invoke Notepad for file in Ubuntu filesystem: “cd /tmp && notepad.exe foo.txt”?

    1. The guidance remains the same: DO NOT MODIFY LINUX FILES USING WINDOWS APPS!

      If you try to open a Linux file using, for example, Notepad, you’ll se a “file not found” type error.

      Again, DO NOT MODIFY LINUX FILES USING WINDOWS APPS! 😉

  3. am says:

    This is fantastic news. Really look forward to using this as a replacement for cygwin. Thank you Microsoft!

  4. Teras says:

    As it seems, it is possible to run Linux *scripts*, not Linux executables from Windows. It would be much more useful to run Linux applications directly. Then would be the perfect time to uninstall Cygwin

    1. Have you tried the following? These are two Linux apps piped together with Bash.

      bash -c “ls / | grep sr”

  5. Alexis says:

    Are we gonna get this on Redstone 1? regards!

    1. No – WSL is a beta feature in RS1 and we can’t afford the resources to back-port the whole thing to RS1. It’ll be coming to RS2 though … or whatever it ends up being called when it ships 😉

      1. Alexis says:

        thanks, this looks great, I’m gonna give a try today and thanks for all the great work, you are making my life so much easy this days, i really appreciated, regards

  6. Myria says:

    Is there any chance that Valgrind could be supported?

    Unrelated: I wish that I could write my own PICO kernel drivers, so that I could make a way to trap all system calls on a process I’m debugging. It’d be useful for “hostile” debugging (e.g. reverse engineering malware).

    1. Not quite yet. We’re doing some work on the Pico infrastructure and API’s, but do aim to document in a future release.

  7. The contributions Microsoft makes towards the open-source and Ubuntu is amazing!!

  8. Keerat Singh says:

    @Rich. Kudos to the team on this wonderful achievement. I recall you mentioning this on the MS-DEV show a while back.
    I was really looking forward to this, I think now I can finally use the gitk GUI executable from Bash. 🙂

  9. George Beeler says:

    I’ve had a real problem automating a moviemaker task where raw video is converted into a video. Can BASH automate this type of task as there does not appear to be a way to script MovieMaker.

    1. No – Bash is primarily a UNIX-compatible environment in which developers can run GNU/UNIX/Linux tools. Although Bash is a great tool for automating UNIX/Linux tools and apps, it’s not necessarily the best solution for automating Windows apps and tools. PowerShell is likely a more powerful option for these scenarios.

      Also, because MovieMaker (as part of Windows Essentials 2012 suite) will reach end of support on January 10 2017, and because MovieMaker is not particularly automatable, you might want to consider moving to a more automatable video conversion tool like ffmpeg.

  10. Reinhard Schuerer says:

    That is really great news. Finally I’ll be able to use the new subsystem

  11. mobluse says:

    Now I can see the Build of Windows from Bash on Ubuntu on Windows:
    /mnt/c/Windows/SysWOW64/WindowsPowerShell/v1.0/powershell.exe -command “(Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’ -Name BuildLab).BuildLab”

    Now this gives me:
    14955.rs_prerelease.161020-1700

    But:
    /mnt/c/Windows/SysWOW64/WindowsPowerShell/v1.0/powershell.exe -command “(Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’ -Name BuildLabEx).BuildLabEx”
    Gives:
    14955.1000.x86fre.rs_prerelease.161020-1700

    But in PowerShell:
    (Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’ -Name BuildLabEx).BuildLabEx
    Gives:
    14955.1000.amd64fre.rs_prerelease.161020-1700

    How can the same registry entry give different processors? X86 vs AMD64.

    1. mobluse says:

      Solved by (was wrong version):
      /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -command “(Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’ -Name BuildLabEx).BuildLabEx”
      Gives:
      14955.1000.amd64fre.rs_prerelease.161020-1700

  12. Demian says:

    This bash stuff is awesome! I was curious about a specific use case. I am a java developer and I need to reference files / directories on the unix side. Currently, I launch my IDE (Intellij) within the VM so my environment is the same as everyone else (mac os mostly) and matches our servers (linux). With this new interop, will the launched Windows app understand a linux file path to something like ‘new File(“/symlink/some/path/to/a/file”)’ where /symlink in Bash on Windows would point to /mnt/c/some/windows/path?

    This functionality would allow me to work on this code directly in Windows without having to use cross-platform file paths in the code. Hopefully this makes sense.

    Thanks much,
    Demian

    1. Yes, your scenario makes complete sense – we’re keen to figure out some key improvements to filesystem mappings, paths, etc.

      However, for now, avoid creating/modifying ANY files in the Linux side of the filesystem using Windows apps: If you do, you’re VERY likely to see data corruption and/or loss since Windows apps don’t know how to maintain Linux file metadata (e.g. sizes, permissions, etc.) required by the Linux filesystem.

  13. Jocala says:

    I’m a Qt developer and I now have the same bash-based build system on Windows/Linux/Mac. Overjoyed is putting it mildly.

    1. LOL 🙂 That’s awesome.

  14. Keerat1563 says:

    Hi Rich

    I am unable to access a jekyll website hosted at 127.0.0.1:4000 served through Bash [Windows 10 Insider build #14951]
    It says the host refused the connection.
    This works on a previous build #14393 as tested by rolling back to a previous build.
    Any suggestions on how to resolve ?

    Regards,
    Keerat

    1. Should be working fine. I just created a Jekyll site and ran `bundle exec jekyll serve`, then browsed to http://127.0.0.1:4000 and immediately saw the Jekyll site.

  15. HeloCheck says:

    Fantastic news indeed I really love the way Microsoft is moving toward the OSS world, for somebody like me who spends 80% of time on MS systems and the remaining 20% on *nix systems this is a welcome news.

    1. Great to hear – thanks for your kind words. We’re sooo excited to be able to make a difference in so many dev’s lives every day 🙂

  16. Emre says:

    Microsoft is reinventing itself. This is fantastic ✌

  17. Alan says:

    What’s the point? Cygwin can do all this and a huge amount more.
    How long do you expect it will take till you support even 0.01% of all that the Core and basic packages of Cygwin/MinGW provide?
    Given how far it has to go it really just looks like another pointless gimmick.

    @Deti, you mentioned Microsoft’s support for open-source and Linux. Yet I don’t see any link to the source code for MS bash.exe on this page; also I suspect the intention is actually to nudge people away from considering Linux as an options rather than supporting it.

    @Rich, just a though. Is MS honouring the intent and sprit of the GNU Bash Licenses.
    https://www.gnu.org/licenses/licenses.html

    1. Hey Alan. Did you read and/or watch the docs/video?

      Using the interop features, you can now invoke any Windows .exe from within Bash making it much more convenient to use as part of your workflow.

      The big benefit of Bash/WSL vs. Cygwin/MSys, etc. is that Bash/WSL runs unmodified Linux binaries on Windows. So if you need to use Ruby Gems, Node packages, etc., which package Linux binaries or which depend on Linux-specific behaviors, file layouts, etc., you can take advantage of Bash/WSL’s ability to run Linux binaries within a genuine Linux environment alongside your existing Windows tools, technologies and workflows.

      Microsoft doesn’t need to publish any of its WSL internal implementation details because there is no GPL code within WSL: The only GPL’ed code that is involved with Bash/WSL is the code used to build the binaries delivered by Canonical … which Canonical delivers within its Ubuntu image that gets downloaded and installed when you install a Bash instance.

      All that Microsoft is doing here is providing a Linux-compatible ABI implementation which can handle Linux syscalls, mapping them to calls into NT Kernel functions where possible, and/or our own implementation of *NIX behaviors that don’t have a direct equivalent within NT.