As touched on in Chapter 2, PowerShell makes life immensely easier by keeping information in its native form: objects. Users expend most of their effort in traditional shells just trying to resuscitate information that the shell converted from its native form to plain text. Tools have evolved that ease the burden of working with plain text, but that job is still significantly more difficult than it needs to be.
Since PowerShell builds on Microsoft’s .NET Framework, native information comes in the form of .NET objects—packages of information and functionality closely related to that information.
Let’s say that you want to get a list of running
processes on your system. In other shells, your command (such as
/bin/ps) generates a plain-text report of the
running processes on your system. To work with that output, you send it
through a bevy of text processing tools—if you are lucky enough to have
generates a list of the running processes on your system. In
contrast to other shells, though, these are full-fidelity
Process objects straight out of the .NET Framework. The .NET Framework documentation describes them as objects that “[provide] access to local and remote processes, and [enable] you to start and stop local system processes.” With those objects in hand, PowerShell makes it trivial for you to access properties of objects (such as their process name or memory ...