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 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 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.

This entry was posted in Programming and tagged , , , , , , . Bookmark the permalink.

9 Responses to Venting On PowerShell

  1. Jeffrey Snover says:

    Your reaction is very similar to my reaction to VMS DCL when I started to use it. I had a long Unix background and I keep thinking, “what a piece of crap, why don’t they just do it the right way”. I banged my head against that wall over and over until one day I just took a deep breath and decided to drill in and see how DCL would do things. What I discovered was that it was a wonderful, thoughtful system. It had consistent naming, syntax and semantics. It allows full naming for self-describing scripts or short naming for great interactive sessions. I just fell in love with it.

    BTW – this is not unlike most developers experience in switching languages. I wrote a lot of Fortran code using the C compiler before it clicked. Then I spent 6 months writing C code with the C++ compiler. Our tools affect the way we think about the problem. Coming from Unix, you’ll think about how to parse text to get what you want. That will cause you some heartburn with PowerShell. (I think we do a reasonable job with Text parsing but I think we could do more for people who want to do everything this way.) If/when you start thinking about things differently, you’ll find that you can do amazingly powerful things with a small amount of effort. e.g.

    get-help * -parameter computername
    get-help * |where {$_.Synopsis -match “WMI”} | Out-GridView
    Get-Eventlog system -EntryType Error |Group {$_.TimeWritten.DayOfYear} -noelement

    Now let’s be clear. VMS DCL has a TON of shortcomings. It’s pipelines where complete crap. It’s utilities where weak as hell (they did have a couple awesome ones though). There wasn’t a week that went by that I didn’t say – Damn – I wish I had a Unix shell to work with. Over time I changed that and said, Damn – I wish I had the best of both worlds. Years later, I went to Microsoft and decided to see if I could build that (incorporating other great influences as well [e.g. AS400, TCL, etc]).

    I appreciate your criticism. I’m not sure what you wanted to do but I think all you had to do was:
    Help Get*
    We use wildcard all over the place, not just for filenames (btw – AS400 does something similar – those were some superstar engineers and they don’t get enough credit for their excellent contributions to our industry).

    I appreciate the criticism – I take it to heart. At the end of the day, we are all about making people successful. I think what we are doing with PowerShell will make more people more successful. Anytime you point out flaws in what we are doing, it helps us understand what we need to do to better help you succeed so we treat the critism as a gift (so please keep it flowing [The post has my email address – feel free to send them to me directly]). That said, let’s be clear – if using Perl/Bash makes you successful – go with god. Successful Windows users is all I’m after – one path or another.

    BTW – given what I can tell about the way you think from your post, I think you might enjoy Bruce Payette’s book PowerShell in Action. Superstar Bruce is the lead dev on the language and one of the many guys on the team that has deep Unix backgrounds. In his book, he explains WHY we do the things we do. Even if you hate PowerShell, I think you’ll enjoy his thinking and they way he explains things. (He is a truly brilliant guy).


    Jeffrey Snover [MSFT]
    Distinguished Engineer
    Visit the Windows PowerShell Team blog at:
    Visit the Windows PowerShell ScriptCenter at:

  2. Jeffrey,

    Let me say that I really appreciate the time you took to respond, and the thought and care that you put into your response. I hesitated writing this article because it’s mostly griping in public over the heartburn experience changing tool sets. You’re absolutely correct that we all go through it, repeatedly. PowerShell just happens to be my personal whipping boy this time. I don’t hate it, it’s just the object causing me pain at the moment. 🙂

    I did some further thought, especially what drove me to publicly air griping that I don’t usually do. I think that the place where I do have legitimate feedback is in the marketing to experienced software engineers whose paradigms have been shaped by Unix. I believe that I’m exactly the type of person who should be competent with PowerShell (if not an outright fan).

    There are so many cool technologies to play with, and they all compete for my limited time. Even though I’ve been exposed to PowerShell’s existence for some time, and played with it from time to time, I haven’t seen any compelling case made for why I as a software engineer should invest time into this tool rather than something else. After all, I have Perl and Python when the crusty old DOS bat file won’t do.

    The fact that I’m investing the time and money into learning PowerShell is more by accident than anything else. There’s part of me inside that feels, oh, what’s a good word… slighted by marketing, like people of my background have been glossed over. PowerShell’s a great tool with a clean design, and I’m late to the party. 🙂

    I don’t know if that makes sense at all.

    And, I will certainly pick up a copy of PowerShell in Action. Knowing why things work the way they do goes a long ways with me.

    As for the example in the article, I wanted to go beyond a step beyond help get* and also grep the summary text. Nevertheless, thanks for the pointer about wildcarding. It’s easy to make assumptions about the way things work, and that small difference is IMHO significant.

    Anyhow, again, thanks for taking the time to respond.


  3. Joe Ryan says:

    I have followed this story as Windows sysadmin who got tired of learning which box to click in Windows and felt more like their need to sell something lead them to advertise that they had the solution only to not have the means to get there if that makes sense. Why create all these Unix aliases as a teaser only to drop the Unix type shell on it’s head after “ls”. I have grown after Powershell’s release more comfortable with Bash and Linux as a comfortable option very quickly. Although I still use Windows mostly for the elegance of the fonts and display system in general the tools that think like human beings are on Unix-like systems. That to me is another reason Apple has had success getting loads of Windows developers and continue to do so. The tools. Why was it so hard to integrate a classic, useful shell. Maybe they feel they are too good for that or that it was going backwards. I think not. Guess how I found your blog. You, the same reason you wrote the post. I tried hammering some simple aliases on Windows 7 cmd.exe, and after not finding anything built in to the shell, I said to myself, “Oh that’s right Powershell is installed by default duh”. Well an hour and a half later and finding 75 or so lines of code I could have Unix like aliases. Overkill I’ll continue to use Cygwin or Ubuntu for my web apps because the tools seem to be made for what we deal with “Text”. We don’t think in .Net objects maybe the system underneath does but we interface best with computers with text we understand. Why is that so hard to get. I think it is pride on their part. I understand Joel Spolsky’s Astronaut Architecting statement more and more every day.

    I understand what prompted your post and I’m sure their are thousands just like us. People are leaving Linux and Windows for the same thing Stability and good tools.
    Thanks for listening

  4. Joe,

    I appreciate your comments. I had forgotten about the Astronaut Architect articles, and re-read them.

    I like to think that I’m fairly pragmatic when it comes to producing software. My approach to a new project is to take the original idea, play with its boundaries to ensure that it’s something the customer will be delighted with, select the most appropriate tool set for the job, and ensure that the project evolves towards the delightful outcome as efficiently as possible in the face of real-life constraints.

    That’s a long-winded way to say the I want the problem space to drive tool selection and methodology.

    Nine months have passed since I wrote this rant. I’ve found that PowerShell, as interesting a technology as it is, doesn’t frequently fall out as the “best tool for the job” for the type of work I typically do. (When it is the best tool, it’s fabulous.) But the infrequency has gutted the amount of time I spent on the tool.

    (I acknowledge that there’s a potential vicious cycle that can prevent you from obtaining the necessary skills to use the tool well in the first place.)

    Regardless, the one thing I am grateful for is the rich selection of overlapping tools we have at our disposal. I don’t believe the computing industry would have advanced explosively if we didn’t have the freedom to innovate specialized tools.

    Thank you again for stopping by and sharing your perspective. 🙂


  5. sam says:

    I think many *nixers get so angry when using PowerShell is because they can’t *LEARN* it the same way that you learn *nix shells. Firstly man pages + grep + massive long established online community make reading about *nix shells very easy. PowerShell has no grep, and so it’s a catch 22 situation “How do I write a decent grep command, without a decent grep command to process help text – oh crap I suppose I’ll just have to actually read the entire friggen man page”. In *nix you can effectively ask the computer “How do I do this”, but in PowerShell it’s not even possible to know how to ask questions until you have written your own scripts in it’s horribly verbose syntax.

    Secondly with say bash, you pipe stuff together and watch it collapse into a heap because of some syntax error. Note though, you *WATCH* it collapse into a heap, you *SEE* where the text isn’t quite getting processed properly. In PowerShell you just get type error, or a method/attribute/reference not found error. This might ultimately make PowerShell more safe in the long run because it doesn’t fall through on error like bash does, but then that makes PowerShell a misnomer. I want POWER I want FREEDOM and I may make mistakes … but those mistakes will be *my* fault, not the shell’s fault. It seems Microsoft want to make it very hard to do things by accident, but as a result they have made everything just very hard.

  6. Andrew says:

    PowerShell has it’s benefits, but those benefits vaporize when you want to something once and quickly and you find in order to do it you have to write swathes of code that with the UI is as simple as clicking a check box or two. This is a very real problem on Windows Core installations. Couple this with quite frankly a lack of documentation on how to achieve various things.

  7. visitor says:

    powershell does have grep, it’s called Select-String. Also I think the reverse could be said when *nix brethren extoll the power of the shell over the GUI. It might have to do with the fact that *nix GUI administration blows donkey chunks. Therefore you can flip the tables. You say we are blind to the power of the CLI, well, you are blind to the power of the GUI. What’s the difference?

    [Edit: I’m loath to do so, but I removed the rest of the comment. The point has been made, and the rest was disrespectful and vulgar. The commenter’s name has been anonymised as a result.]

  8. Sam says:

    “Select-String” doesn’t have anywhere near as much flexibility as grep, I’d like 20% of the flags have been replicated.

    The difference between GUI and CLI is that CLIs are much closer to the underlying API of the program, this means they expose all the power of the program in just a few lines of code. GUIs nearly always have missing functionality, because someone has to go and implement the button for it.

    Of course the main advantage of CLI over GUI is that CLI is scriptable, which is why good sysadms won’t touch windows because they cannot automate processes (or with huge difficulty using super crappy powershell).

    Put bluntly, automation is THE WHOLE POINT OF COMPUTERS, GUIs go completely contrary to that unless you seriously want to start hooking into mouse movements or keyboard shortcuts. I’m far too intelligent to want to mindlessly navigate menus and click buttons, when I can write a script or type a command to do it in a tiny fraction of the time and in a repeatable automatizable way.

  9. garegin says:

    Also another big advantage of the CLI is composition. Something which is impossible in the GUI. I am well aware of the advantages that the CLI offers. Just that the in administration, GUI has its place too.

Leave a Reply