I'm constantly trying to come up with new ways of explaining some of Windows PowerShell's more confusing elements. For a lot of admins, working with objects has proven to be one of themost confusing aspects of the shell - and unfortunately it's also one of the most critical aspects. I've recently been test-driving a new explanation, which I'll share here - and you can let me know what you think.
Still Confused About Objects? Try This Explanation...
First of all, I'll apologize in advance to any developers reading this - I'm about to gloss over some stuff. Methods, for example. In classes, I usually get to those a bit later, after "working with objects" is pretty well established and isn't confusing anymore.
Traditionally, trainers tend to teach objects by providing some real world example - I've used both bicycles and cars. "Cars are objects," the explanation usually goes. "They have properties like their color, make, and manufacturer. Methods make them do things like slow down, speed up, turn left, and so on." Folks with zero programming background still have trouble relating the concept of objects to computers, though. I know I did, when I was first learning. Explanations of objects tend to quickly dive into programming concepts, which in PowerShell isn't immediately necessary. You can, in fact, understand relatively little about objects and still be pretty powerful in the shell.
So now I start with the output of Get-Process. It's a table that you're looking at, right? And it has six or seven columns of information. Well, surely that isn't all the information that the operating system knows about processes! In fact, Windows has a lot more information - it just won't fit on the screen. You can think of it like this: When you run Get-Process, PowerShell constructs a huge table with everything it knows about those processes. Then it whittles down the columns to just those that will fit. Microsoft provides a configuration file that tells it which table columns to display by default.
You can filter what's displayed by simply referring to one of the columns by name. For example, this will filter out the table rows where the Name column doesn't contain "svchost"...
That $_ is a placeholder that represents table rows - you're basically saying, "give me the Name column from every row." $_ only works in a few specific situations where PowerShell is hardcoded to look for it, and this happens to be one of them.
You can also re-sort the rows, again by specifying a column name. And, you can even select different columns, if you prefer.
One neat trick is to force the shell to not use a table, but to instead reformat that giant table into a list. That way, all of the columns - which will now be list entries - can fit onto the screen. This is also a good way to find out what additional table columns are available to you.
Over time in a class, I start going back and forth between "table of information" and "objects," after explaining that "object" simply refers to one of the rows in the table. "Property" is just another name for "table column." After a short period of terminology-readjustment, everyone's working with objects quite happily.
Is this an explanation that would have helped you when you were getting started? Is it one that would help a colleague or coworker? And, what other core PowerShell concepts stumped you or your colleagues? How did you work your way past that confusion?