Tag Archives: difficult

Venting On PowerShell

The bulk of my site consists of personal notes that I make public; it’s mostly informational with a few random bits thrown in. Here I’m breaking with that mold and actually breaking into commentary since I’ve just spent the last couple of hours banging my head against the wall.

As arcane and dated as the Unix-style shell may be, over the decades it has proven itself to be a powerful tool for system administrators, developers, and power users who interact with with Unix-like systems. It’s a capable tool even now in the 21st century.  The stark lack of an equivalent tool in the Windows operating systems has been a long source of heartburn when trying to accomplish similar tasks in an efficient manner. Over the years there have been various attempts to bring Unix-style tools to Windows, (such as cygwin) with varying degrees of success. Nothing really took hold, however.

PowerShell is an attempt to address this gaping hole in the Windows world. For quite some time I didn’t really “get” what problem space PowerShell tries to address. This is because the documentation and web sites surrounding PowerShell never really come out and say, “This is our attempt to create a Unix-style shell based on the core concepts that make the Unix-style shell so successful.” They generally talk about how it’s based on .NET objects, and how everything is a native .NET object, blah blah blah — the focus being on the internals and not the problem space.

Again I ran into a situation where not having a Unix-style shell causes a lot of pain, so I sat down and started to plow through the e-book Mastering PowerShell from the PowerShell.com web site. The first pass through the initial chapters was skimming in order to divine what PowerShell is. I went through the Unix-like examples, and it became clear quickly that PowerShell’s aim is to be a native Windows implementation of the core Unix shell concepts.

The core concept in the Unix shells is that one should be able to arbitrarily chain small, single-purpose utilities together to get the exact data that you want. If there’s something that doesn’t do what you want, then you write a small tool that takes data off of stdin, processes it, and pipes to stdout. Because C is not the most friendly of languages for these types of tasks, “Swiss army knife” languages like Perl evolved. Over time some tools like grep grew less single-purpose as common tasks that took a lot of typing compressed into shorter commands. For the shell user, economy of keystrokes reigns over theoretical purity. Nevertheless, that core paradigm never changed despite the inconsistencies and crazy contradiction that one runs into.

The designers of PowerShell followed this model, that of streaming data from one small utility to the next. The primary difference, which is where web sites and documentation get hung up on, is that whereas the Unix-style shell streams bytes, PowerShell streams .NET object instances. (Unfortunately the designers also brought along inconsistencies and unintuitive behaviour, but that’s a discussion for another day.)

Fortunately for those of us who are comfortable with Unix-style shells, much of the core syntax was adopted wholesale. For example one pipes with the vertical bar (“|”), and redirects to files with “>”. There are a number of pre-defined aliases that make the initial brush with PowerShell superficially Unix-like. For example, one will find aliases for ls, cd, rm, history, sort, etc.

However, when you try to move beyond that thin veneer of compatibility and perform simple and common tasks, your life will become hellish as you unceremoniously plow into that devil that resides in the details. As an example, my search was to replicate the functionality of the instinctive command

help | grep -i get

The answer that I finally was able to track down, is the obvious and intuitive

(help | out-string -stream) | select-string get

(For those with broken sarcasm meters, that was full-on sarcasm.) When searching for an answer, the thing that disappointed me was the common attitude that the “PowerShell paradigm” is more pure and thus far superior to the outmoded Unix-style format. This is, of course, ridiculous because it directly violates economy of motion (keystrokes), a fancy way to say that it can be bloody cumbersome. I heartily recommend a review of Larry Wall’s humourous but insightful virtues of programmers: Laziness, Hubris, and Impatience. I’m tempted to tear into this attitude, but the software world is no stranger to sacrificing usability and intuitiveness on the altar of theoretical purity and overengineering.

Note that this is not a blanket condemnation of PowerShell. I wanted to do a handful of simple commands, and it took me a long time to piece together a series of comparatively convoluted statements. In other words, in those instances PowerShell made the simple difficult. On the other hand, there are some things (like the [xml] data type) that make the difficult drop dead simple. Those things exhibit great elegance.

The long and short of it, from my perspective, is that PowerShell will not be simple for Un*x users to pick up. Expect to bang your head against the wall for some time until you understand PowerShells’ quirks.