Six Observations about 2012 Scripting Games Early Entries

Summary: Microsoft Scripting Guy, Ed Wilson, discusses some of the early entries to the 2012 Windows PowerShell Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. One of the things that is always a challenge in creating the Scripting Games is trying to come up with the right balance between challenge, practicality, and appropriateness. In some respects, it is like attempting to walk a six inch I-beam 100 stories up in the air. It looks more precarious that it really is. But like one sage told Harry Potter, “You best keep your wits about you.” And so it is with the Scripting Games—you best keep your wits about you.

Complexity is not always required

This year, I tried. I really did try to reduce complexity. One of my goals for this year’s Scripting Games is to force you into the documentation (think about using the Get-Help cmdlet on a regular basis) so that you will discover some hidden gem hidden amongst the thousands of parameters that exist for the hundreds of Windows PowerShell cmdlets. Obviously, I was not entirely successful.

The point is this: In Windows PowerShell, lots of tasks are ridiculously simple when you have figured out the secret. Of course, when a parameter exists and it is documented in Get-Help, I am not sure that it really qualifies as a secret—but hey, who am I to argue?

Some things really are easy

It has become nearly a cliché since I first wrote that there are three important cmdlets in Windows PowerShell. These three cmdlets are Get-Help, Get-Command, and Get-Member. It was really important in Windows PowerShell 1.0 when I first set this down. For beginners, in Windows PowerShell 2.0 (and especially in Windows PowerShell 3.0), I do not think that Get-Member is quite as important as the other two discovery cmdlets. This is because each new version adds new cmdlets and additional parameters that bring interesting members to the foreground, therefore make discovering obscure members less important. Even with Windows PowerShell 3.0, using Get-Member is important for the more advanced scripter. But each new version makes it easier to perform common tasks, so digging into the object model becomes less of a daily task. I think that these days, I use Select-Object and Measure-Object more often than I use Get-Member.

Scripting is not required

I know they are called the Scripting Games, but this is more a legacy artifact of the VBScript world that spawned the first Scripting Guys and consequently the first Scripting Games. Nearly all of the Beginner events in this year’s Scripting Games (and many of the Advanced events) can be completed with a one-liner. To some, these famously (or infamously) powerful commands epitomize the elegance of the Windows PowerShell language. You can save a one-liner in a .ps1 file and voila, you have a script. Of course, you can also save your one-liner in a text file if you wish. In fact, I actually do both. I have lots of .txt files that contain various one-line Windows PowerShell commands that I spent a decent amount of time creating; and therefore, I wanted a way to save the product of my brilliance.

Keep in mind that at its most basic element, a Windows PowerShell script is simply a collection of one or more Windows PowerShell commands. If I can type it in the Windows PowerShell console, I can place it in a .ps1 file, and I have a Windows PowerShell script. This is one of the great things about Windows PowerShell—it is a shell. It is also a scripting language. It is also a shell. It is also a scripting language. It is like a chocolate peanut butter cup—it is chocolate, but it is also peanut butter. When I teach a Windows PowerShell class, I generally spend the first two days working exclusively inside the Windows PowerShell console. But, I make it really clear to the students that everything we are doing applies to Windows PowerShell scripting. I love a tweet Jeffery Hicks made when he showed dumping the commands from command history to a .ps1 file and automatically creating a script from his Windows PowerShell console command history. This is the perfect example that working interactively at the Windows PowerShell console is, in a real sense, scripting.

Now, let’s get back to my Windows PowerShell classes. Even after I finally introduce the Windows PowerShell ISE, I still end up doing many examples directly in the Windows PowerShell console. One reason is because the Windows PowerShell console has a built in transcription tool, and the Windows PowerShell ISE does not. Being able to hand out a transcript of everything that I typed in a class makes a great teaching tool. It also prevents writer’s cramp on behalf of the students.

Sometimes it seems that students are disappointed they do not do more traditional scripting in my Windows PowerShell classes. But the simple fact is that in the Windows PowerShell era, quite often scripting is not required. Many traditional tasks that required lengthy and complex scripts in the VBScript world, are simple one-liners in Windows PowerShell. Like I said, if you miss scripting, go ahead and save your one-liners as .ps1 files.

A great work ethic does not require lengthy scripts

In Windows PowerShell, often you do not need to write a big, long, complex script. In fact, I would say that on many occasions, this is true. It has quickly become the rule, rather than the exception. I can also say from experience, at times I am still too quick to fire up the Windows PowerShell ISE. After all these years of exclusively writing Windows PowerShell on nearly a daily basis, I am still surprised at how easy things can be accomplished. So what am I really saying? In Windows PowerShell, often more work goes into producing a one-liner than in creating a 15-line script. When I am making presentations to a Windows PowerShell User Group, I am often asked questions, and I will respond by firing up the Windows PowerShell ISE and dashing off a quick script to illustrate the technique I am trying to explain. At times, someone in the group will ask why I did not do XYZ. Often the answer is that I did not think of doing XYZ. Windows PowerShell is so powerful, that there is often more than one way of accomplishing the same task.

In the end, it is about getting work accomplished

In the real world, and in the real world of the 2012 Scripting Games, the end game is to accomplish work. As long as a script or a command accomplishes the task at hand, it works. Jeffrey Snover once remarked that no one learns Windows PowerShell simply to learn Windows PowerShell. Rather, they use Windows PowerShell to solve a specific problem. This is one thing I try to reflect in the Scripting Games—real-world problems seeking real-world solutions. But I do disagree with Jeffrey in one important respect. I know lots of people who have absolutely fallen in love with Windows PowerShell simply because Windows PowerShell is fun, powerful, and a great tool. Many people, including myself, find ourselves playing with Windows PowerShell and exploring the intricacies of Windows PowerShell because of this fun factor. The person who wrote Space Invaders in Windows PowerShell did not do so because his boss asked him for a Windows PowerShell port of Space Invaders. Rather he did it because Windows PowerShell is so fun to play with, and it is great that it has the ability to create fun games like Space Invaders.

Great solutions to regular problems

One reason I love the Scripting Games is that I also view myself as a learner. Whereas I write solutions to each of the tasks, I am often surprised at the sheer elegance of some of the solutions that come in from the participants. In many cases, I look at code and wonder, “Does that work?” I stare in amazement when it really does. This is one of the most exciting things about Windows PowerShell—there are many many many ways of accomplishing the same tasks. The great thing about the 2012 Scripting Games is that you work out solutions to real-world problems. I have had numerous emails from participants in prior Scripting Games where they thanked me for the games and stated that they had already had occasion to use a script at work that they wrote for the games. Cool. Learning that is fun, and useful—a great concept.

Join me tomorrow when I will continue to talk about some of the concerns I saw while grading scripts.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (10)

  1. mredwilson says:

    @Alex McFarland Specifically for the 2012 Scripting Games pay close attention to the exact requirments of the scenario. If it mentions three specific things that must be included, and you miss one, you will lose 1 point. If mentions adding three things to the code, then you can gain a point for each added thing. Many of the scenarios specifically state you do not need to add comment based code, or other things. If the scenario mentions that you are working interactively on the console, then you are probably looking at a 1 line solution. If the scenario specifically states that you are designing a quick solution to a specific problem it often says avoid complexity. This means go simple. In the real world, it is always about trade-offs. Completely robust code, that can handle a wide variety of potential environments and handles all possible errors will be complex. But if you need a quick script to verify that your backups worked, then you are looking at something very simple with no error checking that will do the job. You know your environment and how it is already set up and can use that to your advantage.

  2. mredwilson says:

    @BigTeddy no new scripting games events over the weekend. This gives the participants a chance to catch up — there are five events revealed right now, the first of which is due at 1201 AM Monday April 9 Pacific Time (-8). This is basically Sunday Night at midnight. Then on Tuesday April 10 at 1201 AM Pacific Time Event 2 is due, and so on. So the weekend is for you to get caught up for next weeks five new events. Your challenge is to review what you have written this past week, review the study guide on the All in One page and to be ready for another great week of PowerShell Scripting.

  3. Bigteddy says:

    Hi Ed.  Will there be no challenges over the weekend?

  4. Anonymous says:

    @bigteddy Nope, only weekdays.  I imagine so that the judges have chance to catch up on weekend.  I'm taking the opportunity to learn a little more whilst I can.

  5. mredwilson says:

    @Mr Killian yes, it generates an error due to a missing closing parenthesis.

  6. Anonymous says:

    It's great hearing someone write about PowerShell who is as passionate about it as I am, or moreso. Thanks for all the hard work, it's really appreciated.

    Enjoy your weekend!

  7. mredwilson says:

    @Mr Killian yes the judges will be working very hard this weekend trying to get caught up. Also you are right, using the weekend going over the learning guides from the all in one page would be very useful. In addition, re-reading the FAQ would be helpful as well (I am not saying that YOU specifically need to reread the FAQ, it is good general advice.

  8. Anonymous says:

    @iamred – I can't compute your comment to me sorry, it chucks up an error.  Something about 'missing parentheses…..' :p

  9. mredwilson says:

    @Cruz_Daniel yes, one great thing about the Scripting Games is that it brings people with a shared interest together. For me it is easy because PowerShell is awesome technology. It is both fun and powerful. This makes for a great combination. I hope you are having fun again this year in the games (and that you are feeling better)…

  10. This was interesting.  PowerShell does make it easy to solve complex issues in only a few lines of code.  Many of the Advanced evens can be solved with very few lines of code; in fact, many my solutions start out as 10-30 line scripts.  However, after adding comment based help, comments in the code, error handling, optimizing (foreach{} vs ForEach-Object), and making sure the code is neat, the script can easily swell to over 150 lines.

    I always want my scripts to be as complete as possible, especially if they are going to be used (or judged!) by someone else.  I suppose the takeaway here is to find a compromise, but it's not always as easy as it sounds. 🙂

Skip to main content