Shell or Scripting Language – It’s Shimmer!

Michael has a blog entry HERE where he opines:

Actually, you could also say, it is an introduction into Windows Powershell from Microsoft. When I skimmed over the document, I came once again to the conclusion that Powershell is not really a shell, but just another scripting language.

He posits the following example from the book as a proof point:

get-process | ForEach-Object { write-host $_.ProcessName $_.CPU}    

This question came up literally dozens of times while developing PowerShell: Are we building a Shell OR are we building a Scripting Language? Over and over again the answer was the same: YES. One of Steve Ballmer’s favorite quotes is around rejecting the “Tyranny of OR”. We often accept these false dichotomies when instead we should be struggling to embrace and deliver AND. If you are a middle aged SNL fan, you’ll recognize this as the Shimmer philosophy where a husband and wife argue whether Shimmer is a floor wax or a desert topping.

Spokesman: [ enters quickly ] Hey, hey, hey, calm down, you two. New Shimmer is both a floor wax and a dessert topping! Here, I’ll spray some on your mop.. [ sprays Shimmer onto mop ] ..and some on your butterscotch pudding. [ sprays Shimmer onto pudding ]

It took lots of hard work (we really had to struggle through a lot of tough issues) but we delivered what we believe is both a command line shell AND a scripting language.

Now let’s take the example that Michael provided. That is not necessarily the way I would have done that particular task but if you look at it, it is very clear what it is doing. I consider this a reasonable example of a self-documenting script. This is super important because scripts need to be shared, they need to be maintained and debugged and they are used to learn. As such, you need to be able write scripts whose effects are obvious. PowerShell allows you to write explicit self-documenting scripts like that. We’ve heard lots of complaints from admins that have to deal with other people’s scripts that were written in “write-only” scripting languages. They were very happy about us embracing this as a goal.

That said, I whole-heartily agree with Michael that if this is what you had to type that on the command line, that would be a pretty painful shell experience. But you don’t. We designed a set of aliases, positional parameters, etc to allow a very pithy command line experience. Here is how I would do that in the command line:

PS> gps | ft ProcessName,CPU    

If you do that a lot, you can define it as a function and invoke it this way:

PS> Function t {gps | ft ProcessName,CPU}
PS> t

Everyone is entitled to their own opinion but I think that is a reasonable shell experience.

At the end of the day, water finds its level. If PowerShell is a good shell, you’ll use it as a shell and if it isn’t you won’t. Ditto for PowerShell as a scripting language. That said, we want it to be great at both so please don’t be shy about telling us about our shortcomings in either scenario – we’ll try to fix them.

Michael – I hope you spend a bit more time looking at how you can use PowerShell as a shell. I think you’ll find what you are looking for but if you can’t, I’d really appreciate it if you would document where it fell short.

Thanks!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx