Learn about Windows PowerShell
Summary: The Scripting Wife learns how to filter output by using the Windows PowerShell Out-Gridview cmdlet.
I am happily anticipating this weekend in Seattle. I leave for Seattle tomorrow evening. I will be participating in a portion of the MVP summit. In addition, I will be teaching a Windows PowerShell class to a group of Microsoft engineers during the remainder of the week. This is my first flight for nearly two years…I just received flight clearance from my doctor. The permission to fly could not have come at a better time. I am looking forward to interacting with various Microsoft MVPs, as well as to teaching the class. Both experiences will be great learning opportunities for me.
I am sitting in my office listening to Etta James on my Zune HD, while I hang out on Twitter for a while. This week has already been great because the Scripting Wife articles have begun to come forth as she begins preparing for the 2011 Scripting Games.
As an aside, Service Pack 1 for Windows 7 and for Windows Server 2008 R2 released to the web on Tuesday. It is a pretty big download, and it took me several hours to download both the x86 and the x64 versions. The nice thing is we have included a decent amount of documentation with this release, so it should proceed smoothly. The documentation includes a deployment guide, a Microsoft Excel spreadsheet that indicates all the included hotfixes and updates, as well as Release Notes and a list of changes. Unfortunately, there is not a single documentation pack download; therefore, you need to download up to six files to get all the documentation and guidance. (See the “Can I download Multiple Files at Once with Internet Explorer in Windows 7” Hey Scripting Guy! blog for information about how to increase the number of simultaneous downloads in Internet Explorer. That blog is a 2009 Summer Scripting Games wrap-up article; therefore, it reviews, critiques, and revises a script that was submitted for that event.)
This week the Scripting Wife has been learning about formatting output in preparation for the 2011 Scripting Games. She is following the 2011 Scripting Games Learning Guide. On Monday, she learned about formatting output and the Format-List cmdlet. On Tuesday, she learned about Format-Wide, and on Wednesday, she worked with table data via the Format-Table cmdlet. Yesterday, she began working with the Out-GridView cmdlet. Today she continues working with Out-GridView.
While I was waiting for Service Pack 1 to download, the Scripting Wife came bounding into my office.
“Are you still grumpy?” she asked.
“Grumpy? Me? Ha!” I exclaimed.
“You have been grumpy all morning, complaining about how slow the Internet is acting today,” she said.
“Oh, yeah. That. I wish we could get faster Internet access around here. The really bad thing is that not only is it taking forever, but the download keeps stopping. Sometimes I feel like it is 1995, and I am sitting on the end of a 28.8 dial-up modem,” I lamented.
“Well while you are waiting for your downloads to complete, why don’t you finish talking to me about the Out-GridView Windows PowerShell cmdlet,” she asked.
“I imagine I can do that,” I said. “Open your Windows PowerShell console and pipel your process information to the Out-Gridview cmdlet,” I said.
She thought for a second, and typed Get-Process and piped it to the Out-GridView cmdlet. The exact key strokes she typed are here (<tab> is the Tab key, <space> is one press of the Space Bar, <enter> is the Enter (or Return) key. The | symbol is the pipe symbol, and on my keyboard it resides above the backslash \ key.)
The command produces no output in the Windows PowerShell console, but it generates a Grid View control shown in the following image.
“Yeah, you showed that to me yesterday,” she said.
“I know that,” I said. “I want to show you how to filter the output. In the Filter box, type the word explore.”
As she typed the first letter in the Filter box, the letter e, the display immediately changed to include only processes that contain the letter e in the process name. This is shown in the following image.
By the time she had typed the entire word explore in the Filter box, the resultant process information changed to display only three processes. She resized the window, and the output is shown here.
“Now click the red X at the end of the filter box to clear the explore filter you added,” I instructed.
“OK. Now what?” she asked.
“Why don’t you add a filter to filter out processes that are using CPU time and have a memory working set that is greater than 20,000,” I suggested.
“That sounds cool, but how do I do that,” she asked in a very logical sounding voice.
“First, use the Add criteria button to choose CPU(s),” I said.
She clicked the blue plus symbol on the Add criteria button beneath the Filter dialog box, and the Add criteria selection menu appeared as shown in the following image.
From the Add criteria menu, she placed a check beside CPU(s), and then clicked the Add button.
“Now what do I do?” she asked.
“You have to click the underlined word contains and select is not empty from the selection menu,” I said.
The selection menu that appeared when she clicked the underlined word contains is shown here.
“Well that is weird,” she said.
“Yeah, just a bit. After you do it a few thousand times, it will feel like second nature,” I said.
“Now I need to choose the memory. Do I use the Add criteria button just like I did to add the CPU(s) property?” she asked.
“Yepper,” I intoned.
The Scripting Wife once again clicks the blue plus symbol on the Add criteria button. She places a check next to the WS(K) item, and clicks the Add button to add the working set memory to her criteria. Now she click the blue underlined is less than or equal to criteria to change it to is greater than or equal to. This is shown in the following image.
The last thing that the Scripting Wife needs to do is add the number 20000 to the box beside the is greater than or equal to criteria, as shown here.
“Well that is pretty cool,” she said. “I will leave you to your waiting for your downloads.”
“Leave me? I thought you came in here to learn Windows PowerShell,” I asked.
“I did. You taught me more about Out-GridView than I really need to know. Now you know that I cannot go to Seattle without getting my nails done. And if I am going to drive all the way into town to get my nails done, I may as well go ahead and get a manicure and a pedicure too. So I imagine I will be gone all day. If I am not back before supper time, and you are hungry, I imagine you know how to pick up the phone and order a pizza,” she said.
“Cool. I get pizza for supper,” I replied.
“Only if I am not back in time for supper,” she said.
“Take your time,” I said.
Suddenly, the slow download did not seem quite so slow. Things are looking up. Pizza tonight and dinner with a bunch of Microsoft Windows PowerShell MVPs tomorrow. Yes, things are definitely looking up.
The Scripting Wife said you can follow her on Twitter if you wish. I invite you to follow me on Twitter or Facebook as well. If you have any questions, send email to me at firstname.lastname@example.org or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Anyway you can bottle this up and put it on Youtube ? This was hilarious and educational at the same time :) ...
On my version less-than-or-equal and greater-than-or-equal is not an option any more, the options I see are the exact same as they are for the CPU(s) and other strings. It is like it handles the values as if they were strings not numbers. The default value is contains. And it is the same for each criteria.
So could you explain me why Out-GridView sorts VM(M), WS(K), PM(K) and NPM(K) as if they were strings not int values?
When I sort them I don't want to see them in alphabetical order.
It absoluetly does not make sense to sort PM(K) as 1060, 107300, 1084,108432, 175, etc...
I would think it is also wrong that the example you mentioned plain fails, there is no " is less than or equal to" to the WS(K) criteria, only "equals", "does not equal" and some other string related criteria.
Is there some kind of configuration that enables Out-GridView to recognize integers? I mean in case it is not the Handles criteria, because for some reason the values of "Handles" is handled as integers. There must be a completely reasonable explanation for this. I can't wait to read it.
It is not all lost:
if I do :
Get-Process | Select-Object -Property * | Out-GridView
or specify the properties one by one
Get-Process | Out-GridView
then everything works properly. All Integers are sorted as such.
I checked with other people running win 8, and it seems they can not reproduce the example in this article either. WS(K) is simply handled as a string (unless they use Select-object-property) and so it can be sorted alphabetically only, the "less than or equal" option is not available only options like "contains" and such.
If you inspect all of the properties carefully you will see that all of the alias properties are strings. IF we do a select * we get only the numeric properties. Look at the headers.
With one we get header for WS "WS(K)" which I an alias that has been converted to (K) by the formatter. With the other we get just WS which is the original unconverted number.
To see how this is done look into the format files.
so then, how do you produce the screenshot above:
@szilard - issue is with PowerShell V2 and V3. Windows 8 has V3 and a newer and fancier grid. This article was written for V2 on Windows 7 or earlier which has the older grid.
No matter how I do this on V2 it sorts correctly. On V3 the column is now a string so it cannot be sorted correctly and it cannot be matched correctly and teh drop down will not show equla/greater/less because it is seen as NaN.
My answer was to use the select to get the real column and then you will have all numbers.
SO you are correct in what you posted. I posted to say that thisis handled differntly in QWIndos 8 and in all systems running V3 because the fields are now strings.
You can edit the formatter file and chhage this back to the V2 behavior and you might post it on 'connect' as a possible bug. Format files can be dynamically loaded as needed to specify alternate default behaviors for compatibility with older scripts. (Blog article needed here!)