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

  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. Tux says:

      Oooh soo amazing…. yeah, right.

      It would have been amazing if Microsoft had made contributions like this 20 years ago. Interop-ability in the other direction (Wine) existed 23 years ago despite having to basically reverse engineer the entirety of Windows internals… And frankly that works better than WSL does STILL.

      Don’t get me wrong I love the fact that Microsoft is going in this direction — it’s incredibly practical for me as a user of both operating systems — but it’s extremely frustrating to hear someone laud Microsoft because they changed their mind and joined “our side” over a decade past when it would have really mattered…

      1. It’s always easy to pick fault with the benefit of hindsight. I prefer to learn from the past, but to look towards the future, and act to benefit the majority. Times change. People change. Ideas change. Goals change.

  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”

    2. Melvin says:

      It’s getting close but not quire ready to replace Cygwin

  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

  20. Peter says:

    The “Unable to translate current working directory. Using C:\WINDOWS\system32” is affecting the “clip.exe” too.
    Fresh installed “Creator Update”.
    It seems to be recognized as Linux FS.

    Any chance to change this behavior?
    Love WSL and waited for this “clip.exe” support, since “Anniversary Update” to get it into the next stable Win Update 🙂

    cheers
    (=PA=)

    Reproduction:
    echo “foobar” | clip.exe

    1. This is caused by Windows apps looking up the current working directory and not being able to find it (since ~/ doesn’t exist as far as Windows is concerned).

      We’ll take a look at removing the warning though.

      1. NK says:

        In Bash for Win 10, I’ve just run a command “cmd.exe /c “dir C:\) and the message “Unable to translate current working directory. Use C:/Windows/System32” appeared, but the command still be executed.
        Would you please tell me the reasons and the way to solve it?

        1. This happens when you run a Windows command-line app from within Linux, when your current working directory is somewhere under your Linux filesystem root, e.g. `~/` – which Windows doesn’t know how to find!

          If you first `cd /mnt/c` and then run `cmd.exe …`, you shouldn’t see this warning.

  21. Blake says:

    Hello, I’m really interested if you guys will make the interop more… interoperable in the future – I’ve been holding off on switching to WSL and still use git bash for most things because I can’t actually edit files on the linux subsystem with a graphical editor like VSCode or Atom. What I’d like to be able to do is have an app in my wsl file system and be able to edit the files directly with an editor installed on the Windows side. Is this something you guys are thinking about supporting in the near future? Thanks

    1. Hey Blake. We couldn’t agree more with you! Reducing the gap between Windows and Linux filesystem interop is not a trivial task, but we do have some improvements planned for future releases! Stay tuned for updates 😉

  22. ouldani says:

    that great but i want to execute notepad without add the extension “.exe”
    i install composer in windows but didn’t work in bach,
    i type “where composer” he give me the correct path but it didn’t work

    1. Create an alias from `notepad` to `notepad.exe`:

      $ alias notepad=”notepad.exe”

  23. Philip Daniels says:

    “That is because when Bash is launched, the Windows path is appended to the Linux path”

    Hi, Is it possible to prevent this? I have node installed in Windows, and am trying to install it in WSL using nvm, and it is getting horribly confused by this. I can probably do it with some bash trickery to remove all /mnt/c directories, but it would be nice if there was a way to not have to deal with it in the first place.

Skip to main content