Weekend Scripter: Where.exe—The What, Why, and How

ScriptingGuy1

Microsoft Scripting Guy Ed Wilson here. The sounds outside seems amplified by the inky darkness that grudgingly gives way to the early morning sun. I am sitting on the front porch sipping a cup of English Breakfast Tea, munching on a freshly baked cinnamon scone, and hanging out on Twitter via my laptop. Having wireless access throughout our house makes possible an Internet life without boundaries. Of course, in my office, I have a gigabit switched ethernet network, but from general roaming around The House That Scripting Built, the 54 Mbps I get from my Wireless G (802.11g) broadband router is sufficient.

As I sipped my morning cup of tea, I reflected on the “work week” that recently passed. Another week on the calendar seems to slip into the sands of time. One hundred and twenty hours are gone—and what was accomplished? Well, let’s see. I spent nearly eight hours in meetings, and at least as much time answering email. I wrote a series of articles on using Windows PowerShell and the Active Directory cmdlets that were pretty cool. I also spent some time on Facebook, and hanging out on Twitter.

Speaking of Twitter, I had an intriguing conversation with a person who is a system administrator and Windows PowerShell scripter from Rotterdam who was talking about the performance of the Get-ChildItem cmdlet when compared to using Where.exe. Hmm … I said.

The first thing to realize is that inside Windows PowerShell, you must use Where.exe if you intend to call the “where command.” The reason for this, is that where is an alias for the Where-Object cmdlet. If you use where without supplying the .exe extension, an error occurs, as shown in the following image.

When I add the .exe extension to the where command, I am rewarded with an output that displays all of the pictures I have put in my Hey, Scripting Guy! Blog posts in the month of June. The /R means to recurse. The command is shown here:

To perform the same command using the Get-ChildItem cmdlet, you would specify the path, and use a path parameter and the recurse switch. This command and the results it produces are shown here:

When I ran the two commands, I noticed that the Get-ChildItem command seemed to take longer to complete. I therefore decided to pull out the Measure-Command cmdlet to see how long each command takes to complete. When using Where.exe, the command takes 1.04 seconds. This is shown here:

When I used the Measure-Command cmdlet to test the performance of the Get-ChildItem cmdlet, it tells me that the command took 5.9 seconds to run. This is shown here:

One of the big things about using Windows PowerShell cmdlets is that they always return objects. When using the Where.exe command, it returns strings. But because the Where.exe command returns strings, it might seem that it is not the best tool to use with Windows PowerShell. However, the path parameter of the Get-Item cmdlet will accept a string, so I can pipe the results of Where.exe to the Foreach-Object cmdlet and inside the script block I can use Get-Item to return a System.IO.FileInfo .NET Framework class. This is command is shown here:

Well, the sun is coming up now, and I think I want to head out to my woodworking shop. Join us tomorrow for another edition of Weekend Scripter.

We invite you to follow us on Twitter or Facebook. If you have any questions, send email to us at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson and Craig Liebendorfer, Scripting Guys

ScriptingGuy1

Follow