Objects in the shell: why PowerShell’s design makes sense to me

A while back, a friend said “PowerShell is what happens when you ask a bunch of drunk lizards to make Bash shitty.” Another friend replied that his understanding is that PowerShell is driven by a desire to “modernize” the shell by piping objects instead of strings. Now knowing that I got my start as a Unix and Linux sysadmin, you might expect me to take the “it’s Bash, except awful” side. But you’d be wrong.

Full disclosure: I have not used PowerShell in any meaningful sense. But from what I know about it, it represents a real improvement over the traditional Unix shell (of whatever flavor) for certain use cases. Some sysadmins lionize the shell script as the pinnacle of sysadminry. This is in part because it’s what we know and also because it’s hard. Oh sure, writing trivial scripts is easy, but writing good, robust scripts? That can be a challenge.

Shell scripts are a glue language, not a programming language (yes, you can write some really complicated stuff in shell scripts, but really what you’re doing is gluing together other commands). PowerShell, in my view, is closer to a programming language that you can script with. This fits well with the evolution in systems administration. Sysadmins in most environments are expected to be able to do some light programming at a minimum. We’re moving to a world where the API is king. Provisioning and configuring infrastructure is now a very code-heavy exercise.

The object focus of PowerShell is truly a compelling feature. I think about all the times I’ve had to use awk, sed, cut, and others to slice up the output of a command in order to feed selective parts into the next or to re-order the output. A machine-parseable medium like JSON or XML makes programmatic gluing much easier.

When running interactively in the shell, strings are much easier for humans to deal with. In those cases, convert the objects to strings. But crippling machine output for the sake of humans doesn’t seem productive. At least not when both can get what they need.

If the Unix shell were being designed today, I think it would have some very PowerShell-like features. PowerShell has the advantage of being a latecomer. As such, it can learn from mistakes of the past without being constrained by legacy limitations. Microsoft is serious about making Windows a DevOps-ready platform, as Jeffrey Snover said at LISA 16. To do this requires a break from historical norms, and that’s not always bad.

3 thoughts on “Objects in the shell: why PowerShell’s design makes sense to me

  1. When I need something more complex than a shell (bash for me) script I shift over to Perl (or folks might go to Python).

    Powershell has always intrigued me but I stopped caring about Windows from an admin standpoint about 6 years ago. It does seem to create that added bit of something to extend the problem space that shell scripting can solve before too much pain sets in.

  2. It does seem to fit in that gap between shell (including Windows Batch) and “real” programming languages like Perl and Python. One thing that may be really interesting is to see if it becomes the de-facto cross-platform sysadmin language now that it is open source and available on Linux. For people who have to manage mixed environments, the remote capabilities make it unique. The real question is will people who have historically been anti-Microsoft (often for good reason) be willing to adopt it.

  3. I have it installed, but not on someplace real. I do need to spend some time, maybe find a tutorial to get to where I could actually use it. Powershell-as-shell is better than cmd, but I have yet to tap into the awesome power of it.

    I think there’s a chance that the Powershell model might catch on, but honestly, I expect that in 2050, programmers and admins will be the only ones with screens, keyboards, terminals and shells, and, with some delta, a sysadmin imported from 1985 could get the hang of it in a day.

Leave a Reply

Your email address will not be published.