Bash on Windows: The Good, the Bad and the Ugly
I have finally managed to put my hands on Bash on Windows and I’m very excited about it. I’ve been writing bash scripts in a vintage-hipster fashion for quite a while now.
While others keep installing huge toolchains to setup their environments, I’ve been using Makefile
and one-off .sh
scripts with just few lines of code, and solving each time with ease pretty much everything I needed.
There has always been a glitch in my process though: I wouldn’t care much about Windows developers. “but …Why“ you ask me? Here’s why:
- why would I care when even
git
offers to install a shell that works quite like a Linux one so you can develop with common repositories? - why would I care when there is even a MSYS2 installer which brings in a proper Linux-like environment with modules natively built for Windows?
Moreover, in the last 8 years I’ve personally never worked with any developer that was using Windows to actually develop anything. It looks like the situation might change soon though, not only because Microsoft these years kept doing awesome things for developers of every Operating System, also because finally the missing, unified environment, everyone can rely on, is coming!
Quick recap: what is Bash and what’s the fuss about it?
Born 26 years ago, Bash is a Unix shell and command language used in both Linux and Darwin (Mac/OSX). The only missing platform since about ever has been Windows, which has its PowerShell or Command Prompt counterparts, yet making it very hard to write a single script that would work out of the box in every platform.
#!/usr/bin/env bash
# these are just comments
# the first on top thought is special
# making this file potentially executable
# and interpreted as bash/shell script
# following a print(string) equivalent
echo 'Hello from Bash!'
If you tap the window sign, you write Bash
and you press enter to open up a shell, you can try the welcoming message directly just typing on it echo 'Hello from Bash!'
Congratulations, you’ve written your first universal shell script that works in every OS (beside mobile OS, you are unlikely to develop much directly in there anyway).
If you’d like to experiment on Windows without installing the Insider Preview build, feel free to try this JavaScript Linux emulator.
The Good
The fact Microsoft decided to move into this direction is not even just good, it’s freaking awesome. Having a unified environment with long standing, battle tested, commands that have worked and run for decades also means better software overall.
It doesn’t matter if Bash
is not the most elegant or powerful programming language on earth, all it matters is that we are going to have a universal scripting language and this is huge.
If you consider the success that JavaScript
inevitably has as universal, omnipresent, programming language, and all the amaizing things developers built around its all-but-perfect syntax or features, you could consider Bash
its older cousin counterpart with admin privileges. (and what could possibly go wrong)
Sarcasm a part, Bash
for Windows, which also is currently a beta preview for developers, works!
- you can
apt-get update
andapt-get upgrade
to automatically receive latest packages - you can use most common and famous shell tools such
curl
,sed
,cat
,tail
,vi
and others (I mean … YES, we finally have also a universal editor we could use anywhere) - you could eventually ssh into every bloody machine on your Home network or even remotely and find out, for the first time, the right env and not a similar-but-different one (telnet, putty, etc)
Much more! From an administrator point of view, things are all looking good and awesome, and this is the good part …
The Bad
To start fair, let’s remember the current version is a insider preview beta version so hopefully most, if not everything, I’m talking about will be resolved by the time the stable, official, release will be out. This is a quick summary of things that don’t work:
- there is no GPU access, meaning that nothing that requires even most basic UI will work. No GTK3, no QT, no Tcl, nothing! Beside writing UIs, this means that if you’d like to use GPU computational power for your backend app, right now you can forget about it.
- even if the shell runs by default as root, most common network operations will fail. Right now I couldn’t even read the local machine IP
- there is a limited hardware access resulting in limited hardware info. No
/proc
useful info, nolspci
, nolsmod
, nothing. You can even trynode -e 'require("os").cpus()'
and find out the shell has no idea about its own CPUs - the Web and its bad User Agent Sniffing practice will curse Windows users “forever“
About last point, imagine I have a Bash console opened and I’m surfing to nodejs.org to install node
in my machine.
There we go: a Windows installer is offered to me, and if I install it, my Bash on Windows won’t ever know. Users and developers will have to dig more in order to find most basic info like: “how the hell do I install node.js that is not the 0.10 legacy version that apt-get
is offering me?“
Of course, you have to go into the other downloads section and find out by yourself.
# how to setup nodejs on Bash for Windows / Linux
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
Cool, follow instructions and that’s it you are … not ready to go anyway :-(
npm failures
I’m not blaming npm
, Bash
, or Windows
, but things aren’t working that well. The following output came after a basic npm install
command on a local folder.
The main issue here is that everything runs as root by default and yet there is some access denied problem. I think Canonical and Microsoft need to collaborate a lot about Bash users and their access privileges on Windows, I understand right now it’s safer this hybrid/fake way but I’m not sure it’s good for interoperability of everything running on it.
The sad story is that right now the best way to develop with nodejs is to use the Windows installer and use the special node shell. Yes, you better install the specially configured one so you’ll be a step closer to what Bash for Windows will become soon.
not even GTK 3
There’s no way, and I’m not even sure if there’ll be any way soon, or at all, to create UI from Bash for Windows. Even the good old GTK UI kit, which runs already native on Darwin (Mac/OSX) quartz, XQuartz, and Linux (all distro) Wayland, Xorg, and many other backends, is unable to run, regardless it’s possible to install it.
You can see on the left the Bash on Windows console full of errors after installing PyGTK, and you can see how smooth and clean is the same install on another console with similar purpose: the Mingw-64 MSYS2 console.
Moreover, if you use the awesome Mingw console, you’ll be able to create GTK applications that run natively on Windows too.
This is again not possible (yet?) with Bash for Windwos, meaning there’s also no GJS support and this is very sad.
The Ugly
Ctrl + Shift + C
, V
, and other combinations of keys don’t work so I’m not sure how to copy and paste if not through the mouse. Having to use a mouse for a console is some sort of sick joke though, and I hope they’ll implement the Linux combination instead.
The Windows/special key, the one that in OSX is the Command one, will probably be reserved for the start menu and generally speaking for Windows operations, and this is fair, but needing to learn a different combo to copy or paste something would be quite annoying.
The other ugly problem I’ve found, beside the user being root by default, is that apt-get
really tries to bring in everything while apt search
does not show only modules compatible with Bash on Windows.
The Web will keep cursing developers with false expectations, since finally there’s no way to tell from a User Agent if the surfer is using Command Prompt, PowerShell, or Bash on Windows to develop so that finally we’ll have to find a way to quickly propose all solutions.
This is also good for Linux overall because there are so many websites that keep ignoring this platform, even if they have a software for it.
Bash doesn’t mean that it has to be painful to find software, info, or it should be treated as second class citizen, Bash finally means everyone could benefit from *nix command line operations.
As Summary
We can finally press the magic keyboard, type in “terminal“ or directly “bash“ and be ready to develop within a unified environment. This is a huge win for developers and I cannot wait to see progress on everything I’ve mentioned and everything else I might have missed!
Huge thanks to Microsoft and Canonical for this effort!