Chapter 21. Part 1 - Creating objects and data output objects. PowerShell in depth - Don Jones, Richard Siddaway

This chapter gives an insight into the “spirit” of PowerShell, its ideology in the field of data transmission over a pipeline, and is necessary to understand the perfect programming style.

Chapter 21. Creating Objects for Output

This chapter contains:
The “object” of your output
creating a custom object (contains information on how to create objects correctly in PoSh)
Work with property collections
')
In previous chapters, we showed you how to create a simple script and turn it into a function. We emphasize that scripts and functions should output one and only one data type; in our previous simple example, we used only one command outputting only one data to the output. But you will undoubtedly get into a situation where you need to execute several commands, combine their output and issue this combination to the output of a function or script. This chapter will show you that the main purpose of creating objects (in the text custom objects) is to combine data from several objects into one and the subsequent output from a script or function. Richard recalls how at one conference the question was asked whether PowerShell has a command that works like Union from SQL. In this chapter, you will become more familiar with PowerShell because you will be working with objects.

21.1 Why are output objects?
PowerShell only produces objects. Objects are the only thing that can happen at the output of the script (or function, from this point everything that applies to the script can be applied to the function). You may need to output only a simple boolean value, but this is also an object. Date is an object. The string or character is an object. More complex data, such as processor or service details, are all represented as objects.

digression: we still see a lot of people displaying data in lines instead of full-fledged objects from their scripts (example of a translator - ie, they concatenate data into a line separated by commas, etc.). Do not do this. You must always issue an object on the way out. If you still do not know how to ask a question on the forum - ask to tell about the withdrawal of objects.

insert from the translator - Posh style differs from the classical programming language; Pos is the language of administration, automation, and “control of large blocks”. You need to strive for maximum simplicity and clarity. Previously, you took the text output of the command and parsed it, and that was correct. In pohe you make an object and operate with an object. The difference is colossal.

Example - you need to look netbios and analyze some data. Below are styling:

#   Function Get-NBTName { #     NBTSTAT,     $data=nbtstat /n | Select-String "<" | where {$_ -notmatch "__MSBROWSE__"} #      $lines=$data | foreach { $_.Line.Trim() } #         #          $lines | foreach { $temp=$_ -split "\s+" [PSCustomObject]@{ Name=$temp[0] NbtCode=$temp[1] Type=$temp[2] Status=$temp[3] } } } 

now we make a function call, sort it and then auto-format it like this:

 PS C:\> Get-NBTName | sort type | Format-Table –Autosize 

at the output we get:

 Name NbtCode Type Status ---- ------- ---- ------ MYCOMPANY <1E> GROUP Registered MYCOMPANY <00> GROUP Registered MYCOMPANY <1D> UNIQUE Registered CLIENT2 <00> UNIQUE Registered CLIENT2 <20> UNIQUE Registered 

Total output of the function Get-NBTName objects that can be passed, sorted, make a sample, etc. No for %%.

One could argue - so what, at the beginning there was a parsing. The answer is that in parsing you parse 1 time - at the input from the output line of the issuing line, and at the command line you always parse at the output input of each function. You will have to do the parsing every time you get output from nbtstat, then you pass it to ping, then you try to do something like tracert and every time you have to go through the lines.

Objects are just data structures that PowerShell understands and can work with. Developers do not need to say this, and we will not explain it.
Creating a custom object allows you to follow the main principle - a script or function should produce only one type of object, for example, formed on the basis of several different WMI calls. When you need to display information that came from several sources, you need to create an object in which to place this information. Let's make a script for reporting purposes only, suppose you don't want to do anything inside, but just want to collect data and pass on.
We use the four commands shown in Listing 21.1. Each one extracts a part of data about a computer (we restrict ourselves to localhost , but it can work on any computer).

Tip: if you create a function using the computer name as a parameter, use $ Env: COMPUTERNAME by default, not localhost or "." . There are cases when you need a machine name, which you can immediately get from the environment variable and save additional steps in the code.

You do not want to display all this information, you only need a part of each of the four conclusions. In Listing 21.1, we get the data and put it into variables; we don't produce any output. This is an unchanged piece of code that we will use to create objects in different ways.

Listing 21.1 Initial commands

 $os = Get-WmiObject –Class Win32_OperatingSystem –comp localhost $cs = Get-WmiObject –Class Win32_ComputerSystem –comp localhost $bios = Get-WmiObject –Class Win32_BIOS –comp localhost $proc = Get-WmiObject –Class Win32_Processor –comp localhost | Select –First 1 

The last of the four teams is slightly different. The first three are an operating system, a computer system, and a bios, they exist by definition in one instance, the processor can often not be one. Since all processors will be the same, we select Select –First 1 . Windows Server 2003 and Windows XP will return a single copy of the Win32_Processor class per kernel, so be aware that the results of using this class will vary depending on the version of the operating system.

Note. In the hotfix, a fix for this problem is available for Windows Server 2003 at support.microsoft.com/kb/932370, given the limited time remaining in the life cycle of this product, it may not be advisable to install it.

Thus, each of our four variables contains one object. This is important for the next technique that we consider.
Council In PowerShell 3 and 4, you can use the Common information model (CIM) cmdlets instead of WMI cmdlets. In the example in this chapter, it doesn’t matter how you get the data — via WMI or CIM.

Insert translator
PowerShell without WMI is not complete, all the power of the draw will unfold if you use WMI (or CIM), in conjunction with remote command execution. According to a note by Siddevey, if the admin knows the rook, but does not know the WMI, then he loses up to 60% of the power of the language. I do not know how it is calculated.

So, the variables are filled, we are ready to insert them into our code.

a continuation