Updated: October 22, 2016
Once upon a time, I wrote an article on Powershell admiring its Linux-like properties. I even had a nice animation therein, to everyone's merriment. Fast forward several years, Microsoft decided to open-source Powershell and make it available on Linux (!), and it is now available for early testing.
I like this idea for many reasons. It allows a more common ground in development and system maintenance, especially since there's also Bash for Windows, so we can see a nice mirroring of efforts. In the long run, this should make the two operating systems cooperate more effectively, and the real winners will be people doing administration, developers, but also end users. Let's see how it works.
My test system is a CentOS 7.2 Xfce box, and it is one of the supported Linux instances. Microsoft currently offers installers for Ubuntu, two LTS generations thereof, and CentOS. The setup is fairly trivial, even if finding the packages for download is a tiny bit convoluted. Install with yum locally, and launch from the command line.
yum install powershell-6.0.0_alpha.9-1.el7.centos.x86_64.rpm
I am not a really advanced Powershell user. But it's a shell, and so you just need to learn the syntax and start using it. Now, can it replace BASH or alike? Well, not really, but that's not the point. Anyhow, I started hammering a few basic commands, just to get the hang of how it works.
At first, the usage model may be a little counter-intuitive to Linux users. But the gist remains the same. The one downside to how Powershell is currently realized is the color code. Yellow on white does not work well, so you might want to use a different terminal theme.
If you struggle, you can always invoke help with: help <command>, or better, get-help <command> - examples, to actually see the proper syntax and how it is used. This is quite helpful. Commands are case-insensitive, although they do have a formal upper-case notation here and there.
Some commands (cmdlets) also have a short version. For example, Get-ChildItem is a rather non-intuitive name for the equivalent functionality to UNIX find, plus it can also be abbreviated to gci. This may be a little confusing at first. But not by much.
gci -path /* -include "igor" -recurse
Another thing that may confuse you is - the root is of course marked with a trailing slash, but to make most of the path-dependent commands work correctly, you should actually add an asterisk after the slash. Go figure. Still, I'm baby-stepping as much as you.
It's all there. Slightly different in look and feel - and definitely in name, but it seems to work fine. The shell was fairly stable. The one exception was that Powershell hanged while measuring time of a very long recursive file search. It just stopped, but I was able to interrupt the execution.
Powershell is very verbose and prone to errors, which may seem alarming, due to the red color and the fact errors become very long blocks of text, much like on Windows. But we are talking innocent things, stuff like permission denied errors during file search on the command line.
Then, to give you another example, the measure-command cmdlet (equivalent to Linux time in a way) requires arguments to be enclosed in curly brackets. If you miss these, you will get a big error that looks quite panicky, but it is in fact quite harmless. The same goes for a lot of other cmdlets.
What about Fedora users?
Well, we know that Microsoft released Powershell for Ubuntu and CentOS. I'm wondering if Fedora classifies. Actually, I'm not wondering. I tested. As it goes, this little experiment was not as smooth as I would have hoped for. Immediately after the installation, and trying to run Powershell, I got a nice, juicy error:
Failed to initialize CoreCLR, HRESULT: 0x80131500
This is a fairly generic error, and there's a rather long discussion on this topic available on GitHub. However, rather than just blindly following suggestions, I wanted to first confirm that the issue was with the libicu dependencies. To wit, I called on the power of strace, which is one of the more handful tools in my ever-growing debugging arsenal.
open("/usr/lib64/libicuuc.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Indeed we have a few missing libraries. The thing is, this package is available on Fedora, only it is a newer version than the one that Powershell expects. I tried to hack around the problem by creating symbolic links, and this did help a little.
ln -s /usr/lib64/libicui18n.so.56 /usr/lib64/libicui18n.so.50
In the end, the error went from a generic startup problem to an issue with symbols inside the shared object. And this is something you cannot resolve arbitrarily.
powershell: symbol lookup error: /opt/microsoft/powershell/6.0.0-alpha.9/System.Globalization.
Native.so: undefined symbol: uloc_getDefault_50
The solution is to download the older version of libicu, extract it somewhere, and then set the library path in a way that would allow Powershell to find and pick the libicu dependencies first, e.g.:
Here we are. It is Year 2016, and you can run BASH on Windows, natively, and you can run Powershell on Linux, natively. Not only is Bob your uncle, you are Bob's uncle, too! I am pleased with this development. It will only benefit everyone in the long run.
Powershell is not my immediate choice for a scripting tool, language and framework, but it does have its merits, and for people who need to maintain a multi-OS environment, it might significantly simplify administration efforts. The early alpha build is stable enough for testing, but I would strongly recommend against heavy testing, especially not with root permissions, and on production systems. Just to be on the safe side. All in all, quite all right. Anyhow, off you go. Time to fiddle with your keyboard.