The Key to Understanding PowerShell – on Windows or Linux
I’ve listened to a few of my Windows-friendly compatriots attempting to explain PowerShell to their Linux colleagues, and it hasn’t always gone well. The problem, I think, is that a lot of Windows folks don’t actually know why PowerShell exists in the first place. Let me explain.
PowerShell _does not exist to automate administrative tasks. _Re-read that a few times until it really sinks in. You see, you start going at the Linux guys with this “automation” argument, and they’re all like, “yeah, man, we’ve had that for always.” The existence of PowerShell on Linux makes no sense if the point of PowerShell is simply automation. In fact, PowerShell as an automation mechanism also _makes no sense on Windows. _Keep in mind that all PowerShell does is built on WMI/CIM and .NET Framework; there was nothing stopping you from using those things in the first place. You didn’t need PowerShell.
The point of PowerShell is that .NET Framework is a terrible surface for systems administrators. Getting anything done correctly in .NET requires you to write an application of some size, compile it, and run it. .NET wasn’t designed with ad-hoc, system-level “scripting” in mind; it’s an application development framework. An empty .NET project starts with dozens of lines of code and configuration; that’s the bare minimum to even start writing code. For admins, it’s too much. Heck, it’s sometimes too much for _developers, _which is why some of them like PowerShell as a “.NET immediate window” so much - they can just bang out a one-liner, hit Enter, and get results.
I’ll argue that all operating systems rely on APIs for command-and-control. If you want to tell Windows to shut down, you need an API to do it. In modern times, that API comes via WMI/CIM or .NET, for the most part. In Linux, if you want to configure Apache to listen to a different port, you need an API. That API comes in the form of a text file. I’ll also argue that, from a systems administration perspective, all APIs suck. In Windows, you’re forced to learn this vast and complex .NET Framework, which is only marginally consistent within itself, and which requires a (relative) ton of code to make do anything. In Linux, you’re forced to learn regular expressions and text parsing, along with a bunch of poorly-interconnected command-line tools that have improbable names invented by Dungeons & Dragons geeks in the 1960s and 1970s. “Grep,” as an API for systems administration, was never a good idea - it’s just what got the job done when your main configuration surface was a bunch of text files.
The entire point of PowerShell is nothing more, nor less, than to wrap a more-consistent, administrator-friendly API around those other sucky APIs. PowerShell is an abstraction layer, and that’s it. Do you know how to conquer up a ServiceController reference in .NET, and ask it to restart a surface? Me neither, nor do I care to learn - I’ll just run Restart-Service, which does all that under the hood. Do you know how to pull a daemon list on Linux, retrieve just the httpd daemon, and restart it? You might, but I don’t, and I don’t care to learn that either - I’ll run Restart-Daemon (which will exist someday, I swear it).
On Windows, PowerShell doesn’t replace .NET. We all know that. It makes .NET easier for an admin to use in the context of administration. On Linux, PowerShell doesn’t replace grepsedawk and all the text files - it simply makes them easier, and more consistent, to use for administration. The point of PowerShell is that it allows us to deal in deterministic data structures (objects) without having to be text-parsing experts. It wraps poorly designed underlying APIs into something with a consistent, admin-focused surface. That’s it.
PowerShell does not posit that, on Linux, grepsedawk is a bad idea. PowerShell simply suggests that those tools, and their friends, are a lot harder to learn and use than they should be. PowerShell’s value-add is not automation - you can do that without PowerShell. PowerShell’s value-add is _better productivity as you automate, _and that’s something anyone should be able to wrap their minds around.
Related Articles
PowerShell Escape Room
PowerShell Escape Room by Michiel Hamers by Michiel Hamers https://about.me/michielhamers/ Why on earth you want to create an Escape Room with PowerShell as backend? I’ve always been a fan of escape rooms, so I decided to create my own for my kids. I wanted to make it something that would be challenging and fun for them, but also educational. I decided to use PowerShell as the backend for the escape room, as I’m a PowerShell developer and I thought it would be a great way to learn more about the language.
Microsoft Graph PowerShell Module: Getting Started Guide
Microsoft Graph PowerShell Module: Getting Started Guide by Jeff Brown Microsoft is retiring the Azure AD Graph API sometime after June 30, 2023 (announcement). This retirement includes the Azure AD PowerShell module. In its place, Microsoft has released the Microsoft Graph PowerShell module. The Microsoft Graph PowerShell module is the next-generation way of managing Microsoft cloud services using PowerShell. If you have used MSOnline or Azure AD PowerShell in the past, you’ll need to read on to learn about this new module.
ICYMI: PowerShell Week of 08-October-2021
Topics include VMWare, Windows 11, Web Reports and more… Special thanks to Robin Dadswell, Prasoon Karunan V, Kiran Patnayakuni and Kevin Laux How to gather your vCenter inventory data with this VMware PowerShell script by Scott Matteson on 7th October Inventory reports are a common request when administering a VMware vCenter environment. Learn how this VMware PowerShell script can make such requests quick and easy Building a Web Report in PowerShell, use the -Force Luke by Chris Noring on 8th October