Shell or Scripting Language – It’s Shimmer!

Shell or Scripting Language – It’s Shimmer!

  • Comments 18

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

Leave a Comment
  • Please add 3 and 5 and type the answer here:
  • Post
  • That is funny. When I show people PowerShell that question is asked and I have responded it's a floor wax and a dessert topping (stealing from SNL).

    Glad I am a middle aged SNL fan :)

    And now I know where to look up my favorite SNL skits.

  • Amen. Trackback: http://blog.sapien.com/current/2007/5/23/do-you-get-it.html

  • Haha, I really like this Shimmer Philosophy. Okay, maybe I am jumping to conclusion too fast. These aliases can reduce your typing efforts, significantly. I agree there are cases where it makes sense to use PowerShell as a shell. However, my main argument is that in most cases you are faster with a GUI tool. For instance, I would never go to the command line to get a list of processes no matter how short the command is. There are so many powerful GUI tools for this (e.g. Process Explorer to name just one). Another problem, I see, is that many will probably use aliases in their scripts, too. This will certainly reduce the readability of PowerShell scripts. Perhaps, it would have been better to focus on just one field of application and put two different products on the market, a scripting language and a shell.  I mean, would you really use a floor wax as a dessert topping? But don’t get me wrong, I like PowerShell. I just can’t imagine using it often as a shell, though.

  • Should have gone the quantum physics way, ie: light is a particle AND a wave.

    Powershell is both a shell and scripting language.

  • I think even though the dichotomy isn't necessarily a valid one in analyzing what something is, it's a valid one when you're trying to decide what audience you're trying to cater to.

    Clearly the practical usability of PowerShell isn't the union of both types, but rather the intersection.

    PowerShell to me is a script language with shell syntax. It's neither a complete shell _nor_ a complete script language.

    It's more limited than either cmd.exe or Python, and only serves to fill that small gap between the two.

    Sorry I'm always so critical of PowerShell but I really think it needs to be cleaned up a lot before it'll be usable by anyone more than those who are willing to spend days to weeks of intensive studying and practice.

  • next to the what shell discussion : Dueling Command Lines in Windows Server 2008 As you also could see

  • > But don’t get me wrong, I like PowerShell. I just can’t imagine using it often as a shell, though.

    I think I see the disconnect.  

    Correct me if I got it wrong but I think you are saying,

      "I can't imagine using any command line shell"

    vs

      "I'd love to use a command line shell but PowerShell isn't good enough".

    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

  • > Sorry I'm always so critical of PowerShell but I really think it needs to be cleaned up a lot before it'll be usable by anyone more than those who are willing to spend days to weeks of intensive studying and practice.

    Don't be sorry!  I love it when people tell us what we need to do to meet their needs.  You're the customer.  Bill pays me to make you successful ("you" in the collective sense :-) ).  If you could take a few minute and let us know where we are falling short, I'd appreciate it.  If you've already done that, just post a pointer so I can reread it.  

    BTW - if the issue is "coverage" (e.g. the # or Cmdlets), it would help if you could tell me which ones are the most important for us to focus on for the next release.

    If you work with us - we'll get it right!

    Thanks reinux!

    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

  • Thanks Jeff.

    I don't think it's any one thing in particular, but the design decision to simply make it as powerful and expressive as can be is what hurts it. Given we can do a lot of things, it's a lot harder and riskier to discover and memorize what we _can't_ do. Also, with so many ways to do the same thing, there's so much variability between code written by different people that I find myself needing to read twice or look things up all the time before I can understand how they work.

    Back to the big thing that I brought up a while ago: http://blogs.msdn.com/powershell/archive/2006/07/23/Issues-with-Windows-PowerShell-syntax.aspx  I now understand the technical necessity for expression and command mode parsing (which is necessary to make PowerShell both a script language and a shell), but I think this is something that could have been avoided if there had been a clearer decision on whether PowerShell was _more of_ a shell or _more of_ a scripting language.

    The ( ) argument list syntax might have been made mandatory for anything that has parameters, or at least in any line of code containing more than one method/command call. Yes that means a little more initial learning for anyone unfamiliar with C style syntax, but it means a lot less confusion and learning in the long run, especially when PowerShell users are going to have to learn the ( ) syntax to make use of PowerShell for anything more than what cmd.exe can already do.

    Obviously these changes are way too big to make now, but here are a few feature requests for the next version:

    -When "new" is implemented, I would prefer it to be an alias to New-Object rather than be a new keyword that behaves slightly differently.

    -Ditch either ps or gps. I prefer keeping ps since it's familiar to Unix users.

    -Ditch either ls or dir. Dir would be a better option to keep since it's familiar to both Windows and Unix users. (On the other hand, when a Windows user sees ls in some PowerShell code, they need to look it up.)

    -Things like the difference between an expression 0 + "3" + 5 and 0 + "3" * 5 should force the user to disambiguify, rather than both being valid. It might even make sense to make the user type 0 + (repeat "3" 5) rather than making "3" * 5 valid syntax.

  • Thanks for the specifics reinux.

    You are correct on the reason we have the 2 parsing modes.  What was a big-bet we made.  So far, I'm still pretty happy with that decision but 3-5 years, we'll have a better understanding of whether that was a good choice or not.

    RE: "ls" vs "dir" and "ps" - The current thinking is that we should have offered a optional compatibility section of the default profile and allow people to opt-in to DOS compatibility vs UNIX compatibility.  

    I agree that ("3" * 5) can cause-a-pause the first time you see it but I have to admit, I just get silly with delight every time I do a ("*" * 80).

    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

  • GUI tools are fine for occasional tasks and they make performing those tasks easier.  GUI tools utterly fail at custom reporting tasks and repetitive administration.  

    Example:  You have to run a report on people who have hard set mailbox size limits different than those on the Exchange store.  For 2000 users, it is unreasonable to say, use GUI tools to find them.

    Example:  You have a service that hangs on several servers, while you are working with a vendor to resolve this issue you need to monitor that service and restart it on a certain error condition and alerts you... a script solves this nicely.  

    Example:  You need to scan all workstations in your domain to check the version of a specific file to make sure that an application has been updated.  

    These are all routine examples of why Windows SysAdmins use scripting languages over GUI tools on a regular basis.  These are all real examples.

  • I currently use it as a full-blown scripting language,and have written thousands of lines of PowerShell code. It is actually quite productive;-) Some things I'm missing however are:

    - Tools for documentation generation for the script code (+ inline documentation conventions).

    - Visual Studio langiage integration with intellisense support

    - Debugging support (better than is available now)

    - Unit test library + code coverage measurements

    Serge

  • Great list Serge!

    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

  • I personally found the two parsing modes refreshing. Sometimes I'll slip into using DOS syntax while other times I may use UNIX syntax.

  • Is there any easy way to rename directory, when difference between new and old name is only in case?

    For example: aaa ===> Aaa

    ------------------------

    Owners of 64-bit Vista (me too) have *two* PowerShells, every with its own (different) settings.

    [*One*]

    C:\Windows\System32\WindowsPowerShell\v1.0\Powershell

    Windows PowerShell

    Copyright (C) 2006 Microsoft Corporation. All rights reserved.

    PS C:\Windows\System32> get-ExecutionPolicy

    RemoteSigned

    PS C:\Windows\System32> exit

    [*Two*]

    C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell

    Windows PowerShell

    Copyright (C) 2006 Microsoft Corporation. All rights reserved.

    PS C:\Windows\System32> get-ExecutionPolicy

    Restricted

    PS C:\Windows\System32> set-ExecutionPolicy RemoteSigned

    PS C:\Windows\System32> get-ExecutionPolicy

    RemoteSigned

    Not too much?

Page 1 of 2 (18 items) 12