PowerGUI 1.0.11 release is just around the corner!

According to Dmitry Sotnikov‘s most recent blog post, the next release of PowerGUI (version 1.0.11) is slated for next week.  It may even be available by the time you read this post!  I have had the great pleasure of beta testing PowerGUI 1.0.11 for the past week or so, and this is another fantastic release of this truly great product.

As with previous upgrades to PowerGUI it only takes a few minutes with the new version to see that the PowerGUI team has been very busy enhancing this product.  I hadn’t even finished the installation of the new version when I became totally distracted after noticing one of the enhancements in this version, the PowerGUI Script Editor.  This feature is great news for the PowerShell Community!  Finally a PowerShell script editor with great features that facilitate writing scripts even when you don’t know the syntax by heart, and a free one to boot!  Working with PowerShell just got much, much easier.

Add to that the performance improvements to the startup time for PowerGUI and all of the bug fixes, and you’ve got yourself another great release from the PowerGUI product team!  For a full list of enhancements and bug fixes, check the PowerGUI Feature Map page.

For those of you who haven’t tried PowerGUI yet, this would be a great release to start with!  It’s free and it adds a ton of value to working with PowerShell so there’s really no reason not to try it if you’re even remotely interested in PowerShell and wondering what all the fuss is about.  Plus there is a very active PowerGUI community where you can post questions, notify the developers about possible defects, watch webcasts to see how it works, and raise enhancement requests.  The PowerGUI team actively monitors and participates in the community, so if you need help with anything or want to start a discussion about using PowerShell with PowerGUI, about PowerGUI itself or about the Quest AD cmdlets, this is the right place to go!  I’m a regular on the community forums and will likely try to respond to your questions if someone from the PowerGUI or Quest AD cmdlets teams doesn’t get back to you first.

Kudos to the PowerGUI team for the fantastic products they’re producing!  I can’t wait to see what they’ll do next!

Kirk out.

Technorati Tags: , , , , , ,

PowerShell Challenge: Processing arguments in a function or script

Recently I was experimenting with passing arguments into a function or a script.  I wanted to see how variable length argument functions or scripts could be created.  Here’s what I had set up in my test script:

param([string[]]$args)
$args

I then saved this script as test.ps1 and called it in PowerShell like this:

.\test.ps1 “1” “2” “3” 

Naturally I expected to see the string values “1”, “2”, and “3” output to the console, each on their own line.

Instead, here is the output I received:

2
3

That’s odd.  Some arguments were output, but not all of them.  What happened to the first argument that I passed in?

In this example, when I execute the test.ps1 script, the PowerShell interpreter looks at the arguments I am passing in and attempts to assign them to the arguments that this script accepts as declared in the param statement.  I only have one argument in my param statement, so PowerShell takes the first argument that was passed in and converts it into the type of the argument declared in the param statement.  That means my “1” string gets converted into an array of strings.  Then PowerShell looks at any remaining arguments and it stores them in an array in the $args variable.  This is a system variable that is used to store all remaining arguments that aren’t matched up to arguments declared in the param statement.

Looking at my example, you can see that I am using the $args variable in my param statement.  This means that when the script is run the first value is converted into an array of strings that is stored in the args variable.  Then the args variable is cleared and the remaining arguments are added to the $args variable array.  Once they are all added, the script is run and the last two arguments are output to the console.  As a result, the first argument gets discarded.

It is interesting to note that when you do this, the $args variable retains its array of strings type within the script.  By default, $args is an array of objects.  If you comment out the param statement in the script, the script will output all objects to the console, and the $args variable will store those objects in an array of type object as expected.

Lesson learned?  Don’t use the $args variable as an argument to a function or a script.

Kirk out.

Technorati Tags: , , ,