Category: PowerShell Challenge

This category contains posts designed to start discussions about PowerShell challenges.

Get your PowerShell game on for the Hacktoberfest challenge!

Kirk Munro6 Comments

Every year the folks at DigitalOcean partner up with GitHub and create a Hacktoberfest challenge during the month of October (henceforth known as #Hacktober). The challenge is always about open source, trying to encourage people to participate more in open source projects. On the Hacktoberfest site, they list projects you can participate in, focusing on projects in Javascript, Bash, C++, Python, Ruby, etc., with project owners tagging issues on their project with #Hacktoberfest so that people participating in the challenge can find things to contribute to.

During the Hacktoberfest challenge over the past few years, if you wanted to do this with PowerShell-based projects it was more difficult. You would have had to find someone who had open source PowerShell modules or scripts that you could participate in, or you could even use your own projects when the Hacktoberfest challenge was just about commits to open source repositories, but it has evolved since then and now it’s all about submitting pull requests to other repositories so you need to start playing nice with other people’s projects. It’s much easier now though, because PowerShell Core is open source, the PowerShellGet and Package Management modules just went open source, much of the documentation is open source, there are other PowerShell modules that are already open source, and more modules are going open source every day. There’s even an open source PowerShell module for DigitalOcean automation (ok, shameless plug, I wrote that one). Also, it doesn’t matter if you’re a developer, a devops engineer, a module author, a casual scripter, a PowerShell user who wants to improve documentation, or a PowerShell community member who has an idea for an RFC that would help improve the language — all of these roles have opportunities for pull requests to be submitted to help make PowerShell better for everyone. Do you know how easy it is to submit a pull request for a PowerShell docs change? Brain. Dead. Simple.

Since PowerShell has so much open source goodness now, this year lets make some noise by raising the visibility of PowerShell open source projects, and show the DigitalOcean Hacktoberfest challenge what the PowerShell community can do! According to the Octoverse, Microsoft has already demonstrated themselves as the organization with the most contributors to open source projects. Let’s take that a step further, and raise the bar by submitting a ton of pull requests against PowerShell projects this month! If you’re up for the challenge, aside from a really cool t-shirt and great stickers for your laptop, you’ll also get the pride of having contributed to something truly great!

Want to get started?  Head on over to the Hacktoberfest site and click on the Start Hacking link to sign up. There are also a lot of great resources on that site if you haven’t done open source pull requests before — just scroll down to the bottom of the page. Then, throughout the month of #Hacktober, spend some time contributing to one of the many great open source PowerShell projects. Note that this isn’t limited to specific pull requests for issues tagged with #Hacktoberfest — any pull request will do.

Then, if you happen to be attending the IT/Dev Connections 2016 conference, consider coming to my Anatomy of a PowerShell Pull Request session where I’ll be talking a lot more about a lot of this kind of thing. And at any time, if your stuck, tap myself or any of the other members of the PowerShell community that are plugged into this open source movement via Twitter, or on the PowerShell Slack channel (you can sign up for that here) and ask for help! Lastly, if you’re a PowerShell open source project owner, consider tagging issues you really want people to look at in #Hacktober with the #Hacktoberfest tag so that they get more attention during this challenge (this isn’t a requirement — it is merely a facility to help community members discover issues they could submit a pull request for).

To keep visibility high and encourage others to participate, as you submit pull requests consider sending out a tweet about them with the #PowerShell and #Hacktober hashtags along with a link to this post so that others can discover the challenge as well!

Are you with me? Let’s make #Hacktober a milestone month for PowerShell open source project pull requests!

Kirk out.

PowerShell Challenge: Converting objects to types defined at runtime

Kirk Munro2 Comments

I was recently working on a function where I had to convert objects to a type that was passed into the function when I came across something that may surprise some people.  Assuming you have a type stored in $type, what is the difference between the following two commands (other than style):

  1. $result = Invoke-Expression “[$type]`$value”
  2. Invoke-Expression “`$result = [$type]`$value”

I don’t have any prizes for this, but I thought it was worth asking just for fun.  I’ll post the solution after people have had some time to take a crack at it.

Solution

It’s been long enough to let people chew on this, so I can share the solution.  Only two people came back to me indicating that they had figured it out: Arnoud Jansveld and Thomas Lee.

The key difference between these is in how data is assigned to the $result variable when using an array.  In the first case, Invoke-Expression returns the converted $value (after it has been case to $type), but that return $value is then implicitly sent to Out-Default, which returns generic objects (boxing), so in the end if you started with an array you have a collection of objects (System.Object[]).  In the second case, the assignment is done inside of Invoke-Expression, before any boxing would occur.  Once the assignment is done, nothing is returned from Invoke-Expression, and you end up with an array of the type you were expecting.

This was just a silly little exercise, but it illustrates an important concept in PowerShell by showing how objects coming out the end of a pipeline are boxed in generic System.Objects.  That knowledge comes in handy from time to time when you are scripting, so it is worth remembering.

Enjoy!

Kirk out.

Share this post:

PowerShell Challenge: Processing arguments in a function or script

Kirk MunroLeave a comment

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: , , ,

PowerShell Challenge: Comparing PSSnapin objects

Kirk Munro3 Comments

When working on my Integrated PowerShell Help PowerPack for PowerGUI the other day I came across something that I haven’t quite figured out yet, so I thought I’d share it here and see if anyone else can contribute.  Here’s the challenge:

(Get-PSSnapin snapinName) -eq (Get-PSSnapin -Registered snapinName)

Assuming that you’ve already added a snapin called snapinName to your PowerShell session using Add-PSSnapin snapinName, why doesn’t this expression return True?

Here are some of the reasons why it seems to me like this should return True:

  1. In both cases, you’re retrieving an object of type System.Management.Automation.PSSnapInInfo.
  2. If you pipe either side of the comparison into Select-Object and specify that you want to see all properties the output will be identical ( | Select-Object -Property *).
  3. If you pipe either side of the comparison into Format-Custom, the output will be identical.
  4. The PowerShell snapin is the same on both sides of the comparison.
  5. In one case you’re asking for a specific PowerShell snapin by name that has been added to the current PowerShell session and in the other case you’re asking for a specific registered PowerShell snapin by name; in both cases, you’re still asking for the same PowerShell snapin.

The only difference I was able to find between these two objects was that the hash code returned from the GetHashCode method was different.

If you know why this test for equality fails and want to share that knowledge, I’d appreciate it.

Kirk out. 

P.S. There is something else odd about PowerShell snapins that I encountered that is related to this.  If you call Add-PSSnapin sNaPiNnAmE, PowerShell adds the snapin and stores it with the name just as you entered it (in this case, as sNaPiNnAmE).  Why?  PowerShell script isn’t case sensitive so the script can find the snapin just fine, but it doesn’t seem logical to add it to the PowerShell session using the same case you used in your script to add it when it could easily retrieve the name from the snapin object itself.  This isn’t really important, but it is just something else I haven’t resolved that has been bothering me.

Technorati Tags: , , ,