Hello VIETNAM!!!!

Wait that doesn’t make much sense, but I like the V.

So today we will talk a lot about variables. These are extra important for scripting, but also fairly important for interactive sessions with PowerShell. Variables are extremely powerful but you have to understand what they really are to make sense of them. So we’ll start with a basic discussion of what a variable actually is and what it isn’t.

A variable is an object that stores data for later use. Man that definition could use some work, so let’s start with something a bit more basic. What is an object? (Hint! It isn’t a thing, this is programming not real life… MAN WHY COULDN’T IT BE REAL LIFE!?) In programming we use the term object to reference any type of data. An object can be as simple as $object = 1, or as complex as $object = [System.Collections.ArrayList] and a whole bunch more. So let’s discuss the various different types of objects and what they mean.

$object = [int]

So the term [int] is a term that implies integer. Now if you can reach back to your grade school math classes you’ll remember that an integer is any whole number. In programming this is only a half truth. The term [int] actually means 232. This means that [int] technically only describes 0 – 4,294,967,295. Now, the funny thing about this is that it is actually still not true. It is true with older programming languages, but in PowerShell we use things called ‘signed ints.’ (Not to be confused with Llama ints, or Dhali ints, while these will make you want to spit, they won’t bring inner peace.) A signed int is quite literally what it sounds like, this was a point of confusion for me for a longer time than I’d like to admit, because I thought ‘signed’ meant like ‘digitally signed’ but it doesn’t. It literally means one of the 32 bits is used to imply either “+” or “-“. So now we are left with 231 bits to represent numbers. This is any WHOLE number between –2,147,483,648 to 2,147,483,647. So in the end, an [int]$object is an object that is a whole number between about -2 billion and 2 billion.

$object = [long]/[float]

These are the lesser known brothers to [int]. They are pretty simple, they represent other numbers. [long] (Which is also signed, because it’s such a celebrity) represents 263, or an inconceivably large number, and it’s negative counter part. And [float] allows for decimals. That’s really all that needs to be said on these.

$object = [string]

So now that we are moving out of the math, we can start to look at the other object types. Our first stop on our programmatic voyage is [string]. Now [string] represents any grouping of characters, and can be basically any length. (Some restrictions do apply, but odds are if you are reading this blog/post they won’t apply to you.) This can be [string]$object = “Hello World!” or it can be [string]$object = “12345” . Now the more astute among you will notice that 12345 is certainly not a [string] but instead an [int]. This is not true due to the way the statement is made, if we say $object = 12345 then we are discussing an [int]$object. If we state $object = “12345” then we are discussing a [string]$object. This is an extremely important distinction, and will cause lots of headaches and bugs in your scripts if you think you are grabbing an [int], but instead are grabbing a [string].

$object = [boolean]

So the last ‘normal’ object we will look at will be a [boolean]. This one is fairly simple, in fact it is the simplest of all the $objects, because it can only equal true or false. When computers look at things, they break all problems down into ‘is true’ or ‘is false’ statements, and take actions based on the results. So, as you can imagine, [boolean] is very important, possibly the most important $object you’ll almost never use. But I’ll explain more on that at a later post.

So now we are getting into the more ‘abstract’ types of $object. There are two basic ones, and then I’ll have a short discussion about how PowerShell uses it’s own $object types to make crazy $object that are very much their own things.

$object = [array]

The [array]$object type is the more straight forward of the two types. Basically it is a collection of objects, that is itself its own object. I know that sounds weird, but bear with me.

So if we look at an example [array] we will see something like this.

[array]$object = @("This","Is","An","Example")

This, I’m sure looks remarkably like a [string], with some extra characters, but it is important to understand the distinction. If we call upon [string]$object = “This Is An Example” we will have “This Is An Example” returned. However if we call upon [array]$object, we will have this returned:


And the truly interesting thing about this is that we can now call upon each ‘line’ of [array] and pull the individual string within it:


(An important note: all arrays, and most anything that the computer generates the list for, starts with 0. Computers don’t believe in 1 I guess… I haven’t figured it out, just remember that [array]$object[0] is the first object in the array. Also of note, you can store any type of data you want in a given entry in [array], it is not limited to [string], nor does it have to be all [string] or all [int], it is flexible that way.)


$object = [hashtable]

Now this object type is really kind of weird. It is like [array] in that it allows for multiple [string] objects (Or any $object type for that matter) to be stored as a single object. However it also allows you to recall these ‘sub-objects’ as attributes, (As opposed to saying [0]-[3] at the end.) and call that ‘sub-object’ back.

An example of this would be:

[hashtable]$object = @{
"UserName" = "nholmes"; `
"Department" = "Infrastructure"; `
"Email" = "nholmes@girindustries.com"; `
"Title" = "Practice Lead" `

The purpose of this is we’ve now defined an object that can be loaded again and again with data. Say we had 20 users, we could create [array] out of this [hashtable] over and over again, and then when we reference a specific [0] in the [array] we can look at the attributes by name and see the value defined.

If this type seems super irrelevant, it becomes much more important as we get into PowerShell cmdlets, as it serves as the base object type for almost all objects that come out of PowerShell.

So the last point I want to cover in this post, which has gotten much longer than I intended, is custom PowerShell Object types. Basically $object in PowerShell can mean a ton of different things. Say we make a cmdlet like:

$object = Get-Mailbox -Identity nholmes@girindustries.com

We will see that $object becomes a [PSObject] type. This is basically a glorified hashtable. We can now inspect attributes of $object as it is a representation of the Get-Mailbox cmdlet it was set to be equal to. Say we entered this:

"Nicholas Holmes"

Is what will be returned because it is the attribute associated with the DisplayName data type. Here is another example:


Which is of course some GUIDs about my mailbox which is hosted on Office 365.

That about wraps up my discussion on $object. If you have any questions or comments please feel free to leave them and I’ll be happy to answer as soon as I can. Also look forward to the next discussion, where we get back to $variables and using them to write scripts. Have a wonderful day everyone!

Leave a Reply

Your email address will not be published. Required fields are marked *