« New Features in Microsoft Exchange Server 2007 | Main | Windows PowerShell in Action »

Putting the Hell in PowerShell

Windows PowerShell in Action by Bruce Payette is turning out to be an excellent book. I’m half way through the 13 chapter book and it’s so well written and interesting that it has become my current Bible. His view on the reasons for certain development decisions during the creation of Monad (PowerShell) is fascinating.

Without giving away any of Bruce’s secrets, (which are worth reading for yourself) he clearly explains the use of the Cmdlets and concepts needed to program with PowerShell. His discussions are clear and very thorough with a smattering of well done code examples. I’m looking forward to the heavier topics in the later chapters. One side note, it’s a great book to start with, but if you already have some scripting or programming knowledge it will be a little easier. Newbie’s beware that he goes pretty deep fast.

So, why is PowerShell a living “Hell”? Well, I really want to get as deep as possible with this, as I see it becoming one of the most powerful administration tools we have. Bruce’s book highlighted the glaring fact that I needed to brush up on my programming skills. So, I’m spending this week in one of our 4152 Core C# classes to get my programming skills ironed out. It’s been a few years since I have had to do the “real” coding stuff, so I need the refresher.

The interesting thing (and Bruce mentions this in his book) the amazing similarities that PowerShell and C# have (you will also notice the Python similarities). In fact, PowerShell can be written in a very terse manner, or it can follow almost an identical C# form. Here’s a little example defining a variable and setting a value.

PS: (short version) $myVar = “abc”

C#: string myVar = “abc”;

PS: (Long version) [string] $myVar = “abc”;

PowerShell even takes the “;”!! This has caused some internal debate here at InterfaceTT. When we create a training course for PowerShell, should we teach it using the long version or the short? The short is fast, easy, and simple to remember, but the long version has its pluses too. One of the biggest pluses is that if students learn the long version, they can easily use the official C# language as well. The syntax conventions are close enough that changing between the two would be much easier. If you want to create your own Cmdlets, you will need the C# skills anyways. So that’s one of my questions, what do scripting engineers think they want to do? Will they want to learn enough to handle C#?

To further the argument, there are several language specifics that are virtually identical to begin with such as the “for” loop.

C#: for (int i = 0; i < 10; i++) {…}

PS: for (int i = 0; i -lt 10; i++) {…}

If you look close, you’ll notice in the condition, the second statement uses a unique style of comparison operator. Bruce Payette discusses this in his book. They didn’t want to use the traditional (<,>) style operators because PowerShell is a shell, and the <,> characters are used for redirection. Instead, they opted to use the UNIX standard for the new shell. I must say, that after spending sometime working with PowerShell/Monad, I agree with their decision. It actually makes since, and they included comparison operators that will test for case sensitivity or non-case sensitivity such as –ilt (non-case sensitive less-than) –clt(case-sensitive less-than) –lt(uses non-case sensitive less than as a default)

Then there are the screaming differences between the two languages. Look at this example of creating an Array in C# and PowerShell. Both examples create a three element string array and stores three names.

C#: string[] myVar = new string[3] { "Jason", "Spike", "Simon" };

PS: $myVar=(“Jason”, “Spike”, “Simon”)

Now, remember, I’m a newbie to this stuff too, so I’m sure there is a way to make it more C# like, but WOW what a difference. Now, I’m a System guy, so I choose the PS way over the more complex developer way.

These are the kind of language challenges that I’m debating on how to handle in a full PowerShell course. Which is best to learn? Is there advantages to learning it the C# way? What do you guys think?

An additional challenge that I’m trying to work out is that PowerShell is an Object-based language, not an Object-oriented one. Is this just semantics? Well, no, its not. In PowerShell I can use or instantiate objects that have been built for me, such as from the .NET Framework, but I can’t actually create my own. (BTW PowerShell is not JIT compiled either, pretty much an interpreted language). I have a lot of questions about this. Can I create classes in C#, strongly name them, put them in the GAC and then instantiate them from PowerShell? Will PowerShell ever allow me to create classes? If so, will it be JIT compiled, and become an official object-oriented language and a .NET language? Will System administrators need these skills? Will they actually need any OOP (Object Oriented Programming) skills?

I love this 4152 class, Jennifer has been doing a great job and it has helped me get my skills back into shape. It would be nice if the Visual Studio Team would Add PowerShell scripting to the VS IDE. Hey Microsoft! How about a little help with that! For now I’ll stick too using Sapien’s Primal Script 4.1 as my IDE.

That’s putting the hell into PowerShell for me right now. Lots of questions, very few answers. But I really love what the PowerShell guys at Microsoft have done. I still have a lot of work to do and a lot of learning to do to catch up. Now I’m moving on to scripting some solutions for my network. I’ll share how it goes with you.

Posted on Thursday, December 7, 2006 at 09:45AM by Registered CommenterJason | Comments1 Comment

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

Finally a blog on powershell that understands what's coming. Great post!! I am struggling with the C# / Python stuff but I have faith that perseverance will pay off and my job will eventually get easier!
December 7, 2006 | Unregistered CommenterSean Casey
Editor Permission Required
You must have editing permission for this entry in order to post comments.