Interop between Windows and Bash


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):

notepad

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:

Adding Windows Folders to the Bash Path

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

3-Alias

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

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”.

nofilenotepad

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/<drive>/…), 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:

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 (34)

  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.

  18. The CLI Guy says:

    Will it be possible to launch a windows console app within the same console window from which the call was made?

    I’m specifically thinking of the following scenario – open bash on windows, launch tmux, open a windows console app within a tmux pane.

    Of course the best solution would be to have multiplexer functionality within the windows console…That would be wonderful!

    1. If only one was able to invoke Windows command-line apps and shells from within Bash … oh … wait! 😀

      You inspired this 🙂 Many thanks! 😀

      https://twitter.com/richturn_ms/status/809563000336052224

  19. Alexandr says:

    Does it work both ways? I mean – can I open bash as process, pipe commands in it and get commands responses back?
    Or kinda bash responses.txt

    1. Yes – that’s exactly what the section under “Capturing Bash output from Windows” demonstrates:

      bash -c "ls /" | select-string sr

Skip to main content