Powershell Fundamentals

June 25, 2010 at 11:13 am (PowerShell, SQLServerPedia Syndication)


I’ve had the opportunity this week to take class with Don Jones (blog | twitter), PowerShell guru and author of PowerShell 2.0 TFM (makes me laugh, each and every time). I’m not even going to attempt to try to teach you some of the amazing information Don has spent the last week pouring into my ears (since most of  it spilled on the floor). But, I do want to pass on some high points, gotchas, tips, insights, that Don communicated to us during the class because they might help you pick up on the fundamentals of PowerShell.

That’s the most important lesson I got out of this week, you need the fundamentals to really start to put PowerShell to work. It’s very easy to make the mistake that I did. I went into PowerShell with a programmer’s background. I have built applications with Paradox Application Language (PAL & OPAL), Basic, Visual Basic, Java, and C# and I’ve been working with the VB-Script scripting language for years including work setting up custom rules in Operations Manager. So, I attacked PowerShell like it was just another language. Problem is, PowerShell isn’t completely just another language. It really does have some fundamental differences that you need to be aware of or you will get side-tracked, as I did. Getting side-tracked will not only keep you from properly learning the abilities of PowerShell, but you’ll miss out on major benefits that the proper construction of PowerShell scripts will convey to you.

What constructs? The one key point that I think I was missing was the fundamental importance of the pipe. It’s not simply a neat way to pass information from one function to the next, it’s how you should be doing a lot of the work. I wasn’t, but I will.

Here, largely taken from my notes, so these are not Don’s precise words (all the time), are some things you might want to know (any & all errors are mine and mine alone):

  • No one is going to be bleeding from the eyes at the end of the course. Great news since I usually bleed from the ears after drinking from the Itzik Ben Gan firehose of information during his classes.
  • Don is convinced that it is Microsoft’s intention to move to a two tier structure of haves & have-nots consisting of the first class citizen of PowerShell users and the second tier citizen that uses only GUI’s. I commented on that at length here.
  • Law #1: Thou shalt ask for help. By this he didn’t just mean asking him for help during the class, but learning how to use PowerShell help. He’s right. The more you know how to access the help system, the better.
  • Use Consolas instead of the raster font. It really did help.
  • If you find yourself messing with text, you’re doing it wrong. Which pretty much invalidates half the scripts I’ve written so far in PowerShell.
  • F-7 to get a quick list of commands. Works wonderfully.
  • Set up a commandlet of the day calendar. He suggested tossing the Dilbert daily cartoon calendar and setting up a commandlet calendar so that you look at a commandlet in detail each day as a learning tool. I’ll be working on mine.
  • If an object binds by PSObject (or psvalue, can’t quite read my notes) it will always only bind by psobject despite what the documentation says. Ok.
  • Invoke-Command and remoting are too flipping cool. Parallel execution of the scripts.
  • Security is built into the product:
    • script exec is prohibited by default
    • Ps1 is not associated with the shell
    • must provide a path to a script
    • underlying security is not bypassed
  • Get a certificate then use and generate nothing but signed scripts. This makes sense and I’ll go to work on it. It’ll change how I post scripts here, but I’ll cope.
  • Don’t modify things out of scope. This is actually a fundamental bad behavior. You can modify stuff out of scope, but that doesn’t mean you should.
  • PowerShell GUI’s are possible, but if you need a multi-form app, there is a wonderful product called visual studio.
  • He had a function he called a “getto breakpoint” he used in v1. I just liked the term.
  • If you’re using FOREACH all over the place, you’re doing it wrong. And there go the other half of my scripts….
  • If all you’re doing is writing C# code in PowerShell, then use C#.
  • While we can do a ton of cool stuff with SQL Server through PowerShell, it’s actually exposed a very stunted set of methods & processes into PowerShell. As a matter of fact, running a query is the one thing it really exposed, which is why I’ve been using SMO so frequently.
  • My words, not Don’s, the ISE stinks, get an editor
  • Trying out Sapien‘s PrimalScript because of the class… it might replace Idera‘s PowerShellPlus in my tool box. We’ll see.

I’m sure there were better & more important things that I should have picked up, but this is the list of items that stood out. It was a great opportunity to get to learn this from Don and I heartily recommend you track down his classes and attend them. You won’t be sorry.

6 Comments

  1. Mark Shay said,

    Your tweets this week on the power (no pun intended) of powershell inspired me to sign up for a class on Powershell and finally embrace it. I am taking a class in less than 2 weeks and I am really looking forward to it.

    Thanks

  2. Chris Walker said,

    You got me all curious now; I started seriously taking a look at PowerShell a few weeks ago and I love it, but I have been using ForEach some and I do use the ISE. What’s wrong with ForEach and what do those other environments provide that the ISE does not? I ought to get a book on this and get demos of those two packages, but I also want to know what you think.

  3. Gethyn Ellis said,

    Nice post and nice set of tweets too. I will be looking to learn more about powershell this year.

  4. scarydba said,

    Mark, great news. I think it’ll make a difference for most people.

    Chris, there’s nothing wrong with the ISE, per se, it’s just very limited in it’s functionality. Other editors, such as the ones from Idera, Sapien, Quest, offer a lot more functionality. That’s all.

    The ForEach, Don pointed out, and I can see in my code, is used instead of of the pipe, which is the intended process within PowerShell. Further, ForEach is used instead of multi-threading calls which are possible within PowerShell V2. Because of some of the limitations of the PowerShell integrations from SQL Server, the ForEach loop may be necessary because you’re probably going to be doing work through SMO, not ust through PowerShell. But you need to know & understand when it’s appropriate to use ForEach and when you’re programming yourself away from the intended PowerShell pipe.

  5. Scott R. said,

    Thanks for the insightful comments and tips.

    I have tinkered with but not yet mastered PowerShell, and the pipe versus ForEach issue you mention sounds a lot like the T-SQL set-oriented versus row-oriented / procedurally-oriented / looping (cursors) approaches that are discussed so frequently. Yes? And probably with many of the same difficulties / challenges of unlearning procedurally-oriented approaches and learning / using set-oriented approaches – where appropriate.

    Scott R.

  6. scarydba said,

    Scott, pretty much, yes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: