Tag Archives: Function

Friday Fun: A Christmas Present for You

Over the years a number of people in the PowerShell community have shared Christmas and holiday related items. I’ve collected them and in some cases tweaked a little bit. This year I decided to wrap them all up in a module for you. This will work in PowerShell 2.0 and later.

As you look through the functions you can probably figure out what some of these functions do, but I don’t want to spoil the surprise. But here’s an example.

Grab a copy of the module and look at the commands within it.

Don’t need to run Prompt because it automatically will run when you load the module. Note that if you remove the module you won’t get your old prompt back. Simply restart PowerShell.

Hoping you have a happy and healthy holiday and a fantastic New Year.

PowerShell Clean Up Tools

021913_2047_WordTest1.pngA few years ago I think I posted some PowerShell clean up tools. These were functions designed to help clear out old files, especially for folders like TEMP. Recently I decided to upgrade them to at least PowerShell 3.0 to take advantage of v3 cmdlets and features. I use these periodically to clean out my temp folders. I should probably set them up as a scheduled job to run monthly, but I haven’t gotten around to that yet. In the mean time, let me show you what I have.

First, I have a function to delete files from a directory that were last modified after a given date.

The function supports -WhatIf so that if I run it, Remove-Item will only show me what it would delete. I use a hashtable to build a set of parameters to splat to Get-ChildItem. I love this technique for building dynamic commands. I use this command on my temp folders to delete files older than the last time the computer booted. My assumption is that anything in TEMP older than the last boot time is fair game for deletion.

If you look at this function, you’ll notice that it only affects files. It leaves folder alone. I suppose I could modify it to remove old folders as well, but there’s a chance the folder might have a newer file somewhere in the hierarchy that shouldn’t be deleted so I decided to simply focus on old files. To clean up folders, I use this:

This command looks for empty folders, or more precisely folders with no files. The function gets all of the top-level folders in the specified path and then searches each folder recursively for any files. If no files are found, the folder is removed.

The two tools are great on their own. To put them to use, I created a small script.

I think of the script as a “canned” PowerShell session. Instead of my typing the commands to clean up a few folders, I simply run the script. I inserted some Write-Host commands so I could know what the script was doing. I clean out all the old files first and then make a second pass to delete any empty folders. I trust it goes without saying that if you want to use these, you have to test in a non-production environment.


More PowerShell Trace Window Fun

On my last Friday Fun, I posted an article about using Internet Explorer as a trace window. The idea was to put debug or trace messages in a separate application. I received a comment on the post that suggested I could do a similar thing using the Debug View utility from Sysinternals. This application is used to capture debug messages so I thought I’d give it a try.

After you download it, you will run to manually run it once to accept licensing terms and setup a filter. I’m assuming you don’t regularly use this program for anything else. Depending on your computer you may not need a filter but it is the best way to work with my Debug-Message function.

The essence of this function is the [System.Diagnostics.Debug]::WriteLine($Message,$Category) line. The Category will show up as a prefix to the message in the Debug View window. I set a filter in Debug View on that category, ie PS Trace*. This function, like my IE trace function, relies on a variable $TraceEnabled to be set to $True. If the dbgview.exe process isn’t running, the function starts it. I have hardcoded the path to dbgview.exe which you’ll need to adjust. The easiest approach is to drop dbgview.exe into your Windows folder or modify your %PATH% variable to include your Sysinternals folder.

Using the function is no different than my IE version. In fact, in my demo script all I needed to do was change which script gets dot-sourced.

I added a “Trace” alias to my new Debug View function so don’t have to change anything else. When I run my script using the -Trace parameter, I get a handy trace window like this.


What’s handy about this utility is that it is easy to save the results to a file. I also don’t have to deal with messy COM objects. If you don’t setup the filter ahead of time you may have a hard time finding the trace messages from your script. But that’s your choice.

What do you think?