Adding Efficiency with PowerShell Type Extensions

The other day I posted an article about custom properties which wrapped up with a look at Update-TypeData. The goal is not so much to make your scripts or modules easier to use, but rather to increase efficiency at the command prompt. When running commands interactively I want to get the information I need as easily as possible. In my PowerShell profile scripts I have code that defines a number of type extensions to make my life easier. I thought I’d share some of them with you.

Continue reading

More PowerShell Laziness

lightbulb-ideaA few days ago I posted an article on using Update-TypeData to provide shortcuts to object properties. These shortcuts might save a few keystrokes typing, especially if you use tab completion. They can also give you more meaningful output. But you can take this even further and save yourself even more typing. How many of you have struggled to type an expression like this:

If you read the last article, you already know that I can use my alias property shortcuts. But you can also define other types of properties. Let’s say I often want to get file sizes in KB, and it is pretty tedious having to use Select-Object all the time with a custom hashtable. Instead I can do this with Update-TypeData:

When defining a ScriptProperty, the $this variable is used instead of $_. Using my previously created aliases, my command is now much easier to write:

With the aliases I can use them anywhere in a PowerShell expression. Let me leave you with one more example:

I often need to get the total value of something, but often I need it in a different format such as MB or GB. Now I have it.

That definitely saves some typing. I should probably do something similar for Maximum and Minimum properties as well.

So, what are you constantly typing? Is it something you could be smarter about? I hope you’ll share so I can take advantage of your laziness, I mean, efficiency!

A Better PowerShell Get Scheduled Job Results

Yesterday I posted a quick update on my code to get the most recent scheduled job result in PowerShell. I had been using a simple script. But the more I thought about it, the more I realized I really did need to turn it into a function with more flexibility. When creating a PowerShell based tool you need to think about who might be using it. Even though I only wanted the last result for all enabled jobs, there might be situations where I wanted say the last 2 or 3. Any maybe I wanted to only get results for a specific job. Or maybe all jobs. The bottom line is that I needed more flexibility. Now I have the Get-ScheduledJobResult function.

The function takes parameters that I can pass to Get-ScheduledJob and Get-Job. For the most part the core functionality remains the same: I get the X number of most recent jobs for scheduled jobs. The difference is that now these values are controlled by parameters. The other benefit to my revision is error handling. Before I had a single pipelined expression, but now I use a Try/Catch block to get the scheduled job by name, using * as the default. You’ll also notice I’m using my own error variable. If there is an error, I can handle it more gracefully. I’ll let you test it with a bogus scheduled job name to see what happens.

But perhaps the biggest change is that I define my own object type, based on the Job object.

For every job result insert a new typename. Because I might have multiple objects I need to insert the typename for each one. As I was working on this I originally was inserting my typename into the Microsoft.PowerShell.ScheduledJob.ScheduledJob object. But my custom formatting wasn’t working property, so I found that by selecting all properties, which has the effect of creating a Selected.Microsoft.PowerShell.ScheduledJob.ScheduledJob my changes worked.

Inserting the typename is only part of the process. In the script file that defines the function, I included code to take advantage of Update-TypeData. In PowerShell 3.0 we no longer need to deal with XML files. Now type updates can be done on-the-fly. So instead of creating my custom properties with Select-Object and custom hash tables, I add them as alias properties. I so something similar to create the Run property.

The last part of my revision is to define the default display property set. The effect is that when I run my function, if I don’t specify any other formatting, by default I’ll see the properties I want.

And I still have access to all of the other properties as well.


Now I have a tool, complete with an alias, with defaults that work for me, but if I need to see something else I can adjust the output based on my parameters. If you want to try this, save the function and type information to the same script file.