Windows Adds Support For Bash Scriptingby Brett Howse on March 30, 2016 2:50 PM EST
- Posted in
- Operating Systems
- Windows 10
With the goal of making more developers use Windows, and to help them move their workflows over to Windows, Microsoft has taken the step to enable Bash scripting natively in Windows 10. This will be a new subsystem, and not an emulation layer, with full access to native Windows functions such as the file system and APIs.
Microsoft partnered with Canonical to provide an Ubuntu based subsystem into Windows. In the keynote, Microsoft spoke about how they have had lots of feedback regarding their Hosted Web App bridge which lets developers take web apps and provide them through the Windows Store as pseudo-native apps. The Web Apps can have access to the Universal Windows Platform (UWP) APIs for things like Live Tiles and Cortana integration, but without a lot of the overhead of re-writing into a native app. But the feedback was that a lot of the development tools they use require Bash scripting making it difficult to do the development on Windows, hindering Web App adoption.
Adding the Ubuntu subsystem into Windows is an interesting solution to this problem. Linux does a lot of things much differently than Windows, including having a case sensitive file system, among other things, so certainly some work would have been done on the back end to enable this in Windows.
This, like many of Microsoft’s announcements over the last year or more, have been about making it easier for devs to work on Windows, and expanding the install base of targeted applications with bridges and Xamarin.
I hope to have some more info on the Bash announcement in the next couple of days.
Post Your CommentPlease log in or sign up to comment.
View All Comments
Pinn - Wednesday, March 30, 2016 - linkPowershell is probably better, but you have enough people with Linux/mac backgrounds to need this kind of thing.
JoeyJoJo123 - Wednesday, March 30, 2016 - linkYo dawg, I heard you like open-source terminal APIs, so we hooked you up with Bash so you can open-source inside your closed-source...
Oh wait... Why would you bother with Bash if you can just use it in a truly open-source operating system?
lmcd - Wednesday, March 30, 2016 - linkYou want some 2% reality with that idealism?
JoeyJoJo123 - Wednesday, March 30, 2016 - linkWould you like 2 cents of reality?
Anything that you can script out in Windows 10 has likely already been done and is in a PowerShell script somewhere on the internet. Meaning, if people need a script, they can google their use-case scenario, such as "transfer all images in one folder to another" and then add "powershell" to that search term in Google. You'll find a fair amount of results and other users that might be able to help you.
Anything that you can script out using Bash has likely already been done on a variety of Linux, Unix, BSD systems. Same thing here as before, quite a few users familiar with Bash and these open-source operating systems.
There's a lot less support for Bash (which could only be done through some kind of terminal emulator before) on Windows 10.
So why would you bother? The people who'll need BASH support on Windows 10 (which this is the only place this is getting official support for, not Windows 7/8, etc.) won't find it easily, so they'll go for the lower-hanging fruit with PowerShell.
If someone REALLY wanted an open-source terminal and support for open-source Bash scripts, they'd already be an open-source operating system to start with.
BlueScreenJunky - Wednesday, March 30, 2016 - linkI think it's not about being open source, it's more about using what you're familiar with. Many developers aren't familiar with powershell and would prefer using bash when they're using windows. Many companies have both Linux and windows servers (for example where I work we used to have storage and web servers running Linux, and Database servers running Windows with SQL Server), in which case I think it would be useful to be able to use the same scripts on all your infrastructure.
I'm not saying it's a killer feature, but it could be a nice addition in some situations.
Samus - Thursday, March 31, 2016 - linkLet's face it, this is surprising coming from Microsoft. Nadella is definitely a different leader than Ballmer and Gates. But some things, like implementing BASH, I find conflicting because Microsoft already has an alternative, superior scripting language. I mean features don't hurt, I'm not complaining, I just find it curious to devote resources to adding a feature like this.
beginner99 - Thursday, March 31, 2016 - linkIt's to get developers to move to Windows. And a company wants to make $$$ and not waste their expensive developer time in rewriting CL-Scripts from bash to powershell. Yes you might find it on the internet, still the guys doing will need to learn PowerShell, adjust all the scripts, test them and document them. Depending on the process that can be a lot of tedious and useless work which hinder develeopers from switching to Windows.
Keep in mind this is ultimately about mobile. More Windows Store devs = more windows mobile Apps.
DanNeely - Thursday, March 31, 2016 - linkIt's not uncommon for a FOSS tool to either only have a bash script for setup/config or to have a .bat file that's significantly out of date or less capable than the .sh that the tool developers primarily use. Reducing cross platform friction here is a good thing.
DanNeely - Thursday, March 31, 2016 - linkIt also looks good from the other direction, eg an ASP.net developer with a Redis layer in the tech stack. On the dev machine you can run the Linux version of Redis directly instead of needing to use a VM.
I think Scott got a little confused about the difference between Emacs and Vi in his editor snark midway down the article though.
easp - Monday, April 4, 2016 - linkWhat you are missing here is that some people just want to get work done, and some people don't have a choice of their operating system kernel.
So, to get work done, they found someone who already scripted a simple solution in bash. They install a few supporting packages with apt-get, maybe download a source tarball, and make it, and then they get to work.
They won't use powershell because their starting point isn't a cmd window, its a scripted workflow that someone else already created on linux, or OSX.