Tag Archives: hash table

Hash Table with Embedded Hash Table and Array

Sometimes I write something—as in some PowerShell—and I feel like, while I don’t need it right now and here today, I should put it somewhere. I just found a screenshot where I did that. Maybe it’ll help someone, and posting it here on my site will likely allow me to find it when I’ll need it, versus looking around on random computers for random screenshots. I would’ve never found this image were I actually looking for it.

I must’ve wondered, can I embed both a hash table and an array in a hashtable? I can. First, however, let’s start with a single, simple array, and a single simple hashtable. Let’s make sure we know these.

An array is a collection—remember that word, as you’ll hear it again in PowerShell (in place of “array”)—of items. In other languages, you might hear it referred to as a list. That’s not a bad visual. I write what I need at the grocery store on a Post-it note. I suppose it’s an array; it is a collection of items that I need at home, whether it be food, cleaning supplies, or something else. In the next example, we’ll create two identical arrays in two different manners—one without and one with the array sub-expression operator—and store them in two separate variables.

$ArrayWithoutOperator = 'e','f','g'
$ArrayWithOperator = @('e','f','g')
$ArrayWithoutOperator
e
f
g
$ArrayWithOperator
e
f
g

Let’s prove that at least one of these is an array. While I practically never use Format-Table, I’ve used it in this example to ensure all the output is packed as closely as possible to the left.

ArrayWithoutOperator.GetType() | Format-Table -AutoSize
IsPublic IsSerial Name     BaseType
-------- -------- ----     --------
True     True     Object[] System.Array

It is!

A hash table—and this is my favorite way in which to explain it—is an associative array. Huh? It’s still an array or a list, but now, each item has an association. Each item in the array contains a key and a value. Take a look, keeping in mind that PowerShell will label the keys with “Name” (while the value will be labeled with “Value”).

$Hashtable = @{'mid1' = 'c';'mid2' = 'd'}
$Hashtable
Name                           Value
----                           -----
mid2                           d
mid1                           c

Now, let’s recreate our array and our hash table inside of another hash table. I’m going to show this using both a single line and multiple lines. It’s important to see those semicolons.

@{'top1' = 'a';'top2' = 'b';'top3' = @{'mid1' = 'c';'mid2' = 'd'}; 'bottom1' = @('e','f','g')}

@{
    'top1'    = 'a'
    'top2'    = 'b'
    'top3'    = @{'mid1' = 'c';'mid2' = 'd'}
    'bottom1' = @('e','f','g')
}
Name                           Value
----                           -----
top2                           b
bottom1                        {e, f, g}
top3                           {[mid2, d], [mid1, c]}
top1                           a

That output is painful. As you may have been able to guess, based on the values, I wanted to see elements labeled using “top” at the top of this list, and the element using “bottom” at the bottom. This is how hash tables work in PowerShell in my experience: You’re not going to get it back the way you might expect. Therefore, you’re going to need to know about the ordered attribute which you can apply to a hash table to create an ordered dictionary.

[ordered]@{
    'top1'    = 'a'
    'top2'    = 'b'
    'top3'    = @{'mid1' = 'c';'mid2' = 'd'}
    'bottom1' = @('e','f','g')
}
Name                           Value
----                           -----
top1                           a
top2                           b
top3                           {[mid2, d], [mid1, c]}
bottom1                        {e, f, g}

Now that we have it in the order in which we expect, let’s pay a bit more attention to the associated values for each key. The key top3 is our embedded, or nested, hash table. We can see the representation in the value, where the nested keys and associated value are displayed as [mid2, d], [mid1, c] indicating a hash table (or associative array). Our value for the bottom1 key is e, f, g, indicating an array. And as easy as that, a hash table can be a container for additional hash tables and arrays.

CSV Break Down

I wrote a post recently, but a while back—it is kind of both now. It was about arrays and hash tables. I highlighted the differences between them and who knew, it turned out to be a success. There was a good amount of sharing of the post on Twitter and my same-day visitor count jumped up a fair amount above my average, which is typically around 175 visits per weekday. I do not know who these people are that do not use PowerShell on the weekends but get your priorities straight. Fine, maybe it is me.

The above image indicates I brought in nearly 400 visitors the same day it was published—not bad. There were people in the PowerShell subreddit using the words “array” and “hash table” incorrectly and whatever just took over in me and did what it does to help clarify things for people in the PowerShell community. I have said it before: I have no problem revisiting the things I have already learned about PowerShell. There is a good deal to know, and so any opportunity to learn something you have already learned—we will call that review, right—is okay. I review these concepts all the time; I can only know if I know it by checking! And usually, I have forgotten something. The whole, “If you don’t use it, you lose it” saying, applies to PowerShell, too.

There was another post I did more recently, and while it was not as popular, I liked it. It used a CSV file of links—think, URLs—to create a menu system that could open links as they were chosen inside PowerShell. Good enough for me to push my post count up by one. I will have been writing about PowerShell for eight years in June 2022. Just maybe I can get to 416 posts by then making my average one post per week for eight straight years. Even if I do not make it, to even be this close is a feat. I must like PowerShell.

As I was working with a CSV for that most recent post, I read another PowerShell Reddit post where someone was talking about arrays in conjunction with CSVs. I do not have a link for that post, and I am not sure how much it would apply, but it did get me wondering about the type of variable you end up with when you import a CSV. Do you know by heart!? Care to guess? Let’s bring back the CSV we used in the last post. It will work fine to get us the answers we need.

Title,Link,Note
PowerShell GitHub,https://github.com/PowerShell/PowerShell,
PowerShell GitHub Issues,https://github.com/PowerShell/PowerShell/issues,
PowerShell Docs GitHub,https://github.com/MicrosoftDocs/PowerShell-Docs,
Powershell Docs GitHub Issues,https://github.com/MicrosoftDocs/PowerShell-Docs/issues,
PowerShell Docs,https://docs.microsoft.com/en-us/powershell,
PowerShell Gallery,https://www.powershellgallery.com,
PowerShell Reddit,https://www.reddit.com/r/PowerShell,
Twitter Legends @jeffhicks,https://twitter.com/JeffHicks,
Twitter Legends @jsnover,https://twitter.com/jsnover,
Twitter Legends @concentrateddon, https://twitter.com/concentrateddon,
TechCrunch.com,https://techcrunch.com/,Tech News
Cnet.com,https://www.cnet.com/,Tech News
Gizmodo.com,https://gizmodo.com/,Tech News
9to5mac.com,https://9to5mac.com/,Tech News
Engadget.com,https://www.engadget.com/,Tech News
Wired.com,https://www.wired.com/,Tech News
TechRadar.com,https://www.techradar.com/,News
Axios.com,https://www.axios.com/,News

If we assume the above CSV file is stored in the below path, then the Import-CSV command will supply us with the below results. Further below in the example, we will import it a second time and store that in the $CSVFile variable. From there, we will take a closer look at it. What do we have once it is imported and stored in our variable?

[PS7.2.1][C:\] Import-Csv -Path 'C:\users\tommymaynard\Desktop\Links.csv'

Title                            Link                                                    Note
-----                            ----                                                    ----
PowerShell GitHub                https://github.com/PowerShell/PowerShell
PowerShell GitHub Issues         https://github.com/PowerShell/PowerShell/issues
PowerShell Docs GitHub           https://github.com/MicrosoftDocs/PowerShell-Docs
Powershell Docs GitHub Issues    https://github.com/MicrosoftDocs/PowerShell-Docs/issues
PowerShell Docs                  https://docs.microsoft.com/en-us/powershell
PowerShell Gallery               https://www.powershellgallery.com
PowerShell Reddit                https://www.reddit.com/r/PowerShell
Twitter Legends @jeffhicks       https://twitter.com/JeffHicks
Twitter Legends @jsnover         https://twitter.com/jsnover
Twitter Legends @concentrateddon https://twitter.com/concentrateddon
TechCrunch.com                   https://techcrunch.com/                                 Tech News
Cnet.com                         https://www.cnet.com/                                   Tech News
Gizmodo.com                      https://gizmodo.com/                                    Tech News
9to5mac.com                      https://9to5mac.com/                                    Tech News
Engadget.com                     https://www.engadget.com/                               Tech News
Wired.com                        https://www.wired.com/                                  Tech News
TechRadar.com                    https://www.techradar.com/                              News
Axios.com                        https://www.axios.com/                                  News

[PS7.2.1][C:\] $CSVFile = Import-Csv -Path 'C:\users\tommymaynard\Desktop\Links.csv'
[PS7.2.1][C:\] $CSVFile.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

It is an array! That makes perfect sense, right!? It is a list of values. Each row in the CSV file is a single value, in the array. Sure, each row has the potential of containing multiple values (Title, Link, Note), but each containing row is one single element in the array. The two commands below do the same thing. They return the first row, or element, in the CSV file, as it is stored in the $CSVFile variable.

[PS7.2.1][C:\] $CSVFile[0]

Title             Link                                     Note
-----             ----                                     ----
PowerShell GitHub https://github.com/PowerShell/PowerShell

[PS7.2.1][C:\] $CSVFile | Select-Object -First 1

Title             Link                                     Note
-----             ----                                     ----
PowerShell GitHub https://github.com/PowerShell/PowerShell

Just putting this out there, but we did not even have to use the .GetType() method earlier, to know this was an array. The minute we were able to use a numeric index ([0]), we should have known. I do not know about you, but this got me wondering about two things: One, where did the header row go? As we saw, it had nothing to do with index [0], and two, if each row is an element in an array, what is inside each element? How are the previous columns represented? Let’s answer these.

Before we do, though, a quick reminder: There is really no need to know the things we are discussing to use CSV files and the Import-CSV command. This happens whether we care to know it or not. It is just that I wanted to know what was happening and so I brought you with me. Back to the discussion.

As we have seen, the header row, as we may want to picture it, is gone. It found a place though. Several even. It is stored once per array element, or line or row, if you will, within the $CSVFile variable. What does that even mean!? That is answered by viewing the type of object returned when we view a single element in the array. The below examples use the .GetType() method to return the type of just index [0]. It is a PSCustomObject! We saw the output of this in the last two examples, however, we may have not put it together from just that. Let’s pipe index [0] to the Get-Member command and see what we recognize.

[PS7.2.1][C:\] $CSVFile[0].GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    PSCustomObject                           System.Object

[PS7.2.1][C:\] $CSVFile[0] | Get-Member

   TypeName: System.Management.Automation.PSCustomObject

Name        MemberType   Definition
----        ----------   ----------
Equals      Method       bool Equals(System.Object obj)
GetHashCode Method       int GetHashCode()
GetType     Method       type GetType()
ToString    Method       string ToString()
Link        NoteProperty string Link=https://github.com/PowerShell/PowerShell
Note        NoteProperty string Note=
Title       NoteProperty string Title=PowerShell GitHub

Each column of the CSV has become a NoteProperty in the PSCustomObject. Each name is a column header and each corresponding value has become a Definition. Each definition is a string that includes an entry such as <header>=<value>. Knowing that it makes sense that each of the following examples indicates that their type is a string.

[PS7.2.1][C:\] $CSVFile[0].Title
PowerShell GitHub
[PS7.2.1][C:\] $CSVFile[0].Title.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

[PS7.2.1][C:\] $CSVFile[0].Link.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

[PS7.2.1][C:\] $CSVFile[0].Note.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

While we do not need to know these things to import a CSV file and use it as a part of an assignment or project, there is value in understanding what the command does with each row and the values in each row of a CSV file.

There is a Difference: Arrays Versus Hash Tables

After reading a short post on the PowerShell subreddit recently, I was compelled to write a quick post here about arrays and hash tables. The concepts are similar, but the two are different, meaning that — interruption! There have now been two posts where the OP didn’t know one versus the other. It is basic stuff, sure, but it is important stuff.

Anyway, talking about one when you mean the other isn’t going to be okay any longer — it really never was. While someone mentioned the incorrect usage in the thread, writing, for me, still felt necessary and potentially beneficial.

Instead of writing my own definitions, let’s use Microsoft’s. We’ll begin with an array: “Data structures designed to store collections of items.“ If you think of a variable, back when you learned about those the first time, you probably learn how to store a single value in your variable. Okay good. This time we’re going to store multiple values in a single variable. That is what this data structure provides.

We are beginning with a simple variable that contains a simple, single value. Not much to it.

[PS7.2.0][C:\] $SingleValue = 'One thing'
[PS7.2.0][C:\] $SingleValue
One thing
[PS7.2.0][C:\] $SingleValue.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

Now, let’s work with arrays. We’re still going to use a single variable, we’re just going to load it up with a different data structure that’s going to let us store multiple values in it. We actually don’t have to do much to make this happen, so here we go.

In this example, we’re creating a variable named $Array01. We’re storing the numeric values of 1, 2, and 3 inside the variable as an array.

[PS7.2.0][C:\] $Array01 = 1,2,3
[PS7.2.0][C:\] $Array01
1
2
3
[PS7.2.0][C:\] $Array01.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

Well, that was easy. This next example is the same as above, however, it includes @() around our numeric values. This operator — the array sub-expression operator — takes whatever is inside it and makes it into an array.

[PS7.2.0][C:\] $Array02 = @(4,5,6)
[PS7.2.0][C:\] $Array02
4
5
6
[PS7.2.0][C:\] $Array02.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

The array sub-expression operator will even make an array of nothing.

[PS7.2.0][C:\] $Array03 = @()
[PS7.2.0][C:\] $Array03
[PS7.2.0][C:\] $Array03.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

Here is one you probably do not see often. The comma in front of the 7 will indicate to PowerShell to create an array that contains a single value, which we will prove when we start returning the count of our various arrays.

[PS7.2.0][C:\] $Array04 = ,7
[PS7.2.0][C:\] $Array04
7
[PS7.2.0][C:\] $Array04.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

[PS7.2.0][C:\] $Array04.Count
1
[PS7.2.0][C:\] $Array03.Count
0
[PS7.2.0][C:\] $Array02.Count
3
[PS7.2.0][C:\] $Array01.Count
3

Do you get it? It is a data structure designed to accommodate multiple values. You did not see it here yet, but arrays can hold strings (words or sentences), just as easily as numbers. You can even mix them in the same array and store them in a single variable.

This array, stored in the $Array05 variable contains five different colors.

[PS7.2.0][C:\] $Array05 = 'black','red','green','blue','brown'
[PS7.2.0][C:\] $Array05
black
red
green
blue
brown

Each item in an array can be referenced by an index — a number that represents its location. It is a positional place in line. The first element, or item in the array — black in our case — is in index zero. This is because arrays are always zero-based. This means red would be in index 1, green in index 2, blue in 3, and brown in 4. Zero through four is five, as in five total elements, or values, in our array. Let’s verify.

[PS7.2.0][C:\] $Array05[0]
black
[PS7.2.0][C:\] $Array05[1]
red
[PS7.2.0][C:\] $Array05[2]
green
[PS7.2.0][C:\] $Array05[3]
blue
[PS7.2.0][C:\] $Array05[4]
brown
[PS7.2.0][C:\]

Let’s try some other things! While not often used in my day-to-day, we can perform arithmetic on the indexes. We can even use the range operator (..) and go forward and backward through our elements. What else… Oh, let’s try some negative indexes numbers, too. Those work in reverse from the end of the array to the beginning.

[PS7.2.0][C:\] $Array05[3-3]
black
[PS7.2.0][C:\] $Array05[2+1]
blue
[PS7.2.0][C:\] $Array05[0..4]
black
red
green
blue
brown
[PS7.2.0][C:\] $Array05[4..0]
brown
blue
green
red
black
[PS7.2.0][C:\] $Array05[-1]
brown
[PS7.2.0][C:\] $Array05[-2]
blue
[PS7.2.0][C:\] $Array05[-3]
green
[PS7.2.0][C:\] $Array05[-4]
red
[PS7.2.0][C:\] $Array05[-5]
black

Hash tables have a good number of similarities to arrays, and perhaps that is the reason why there is some confusion. Microsoft even uses the word array to describe them: “A hash table, also known as a dictionary or associative array, is a compact data structure that stores one or more key/value pairs.” I don’t use the words associative array often enough, but I should; I like it.

To the person on Reddit that called hash tables, hashmaps, and just maps: No. I believe that term is a carryover from maybe Java. In my experience, I have not heard it in the PowerShell community.

Anyway, arrays and associative arrays are both data structures. They can both hold multiple values, and they can both be stored in a single variable. The difference is keys and values. Arrays hold single items in each index, while a hash table holds a key-value pair in each.

Before we fill this up, let’s create an empty hash table. Notice the difference between this and the array. If it is used for an array, the operator will always be an instant giveaway: @() is for arrays, and @{} is for hash tables. Notice my liberal use of the GetType() method in this post; it’ll help you make object determinations, so you can always know which you’re working with, without having to view, or see, the data stored in the data structure.

[PS7.2.0][C:\] $Hash01 = @{}
[PS7.2.0][C:\] $Hash01
[PS7.2.0][C:\] $Hash01.Count
0
[PS7.2.0][C:\] $Hash01.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Hashtable                                System.Object

Now, let’s populate a hash table… in VS Code. Somethings I would just rather not demonstrate in the console.

$Hash02 = @{
    Dad = 'David'
    Mom = 'Betty'
    Daughter = 'Janice'
    Son = 'Bryan'
}
$Hash02
Name                           Value
----                           -----
Son                            Bryan
Dad                            David
Mom                            Betty
Daughter                       Janice

This also could have been written in a couple of other ways.

$Hash02 = @{
    Dad = 'David'; Mom = 'Betty'; Daughter = 'Janice'; Son = 'Bryan'
}
$Hash02 = @{
    Dad      = 'David'
    Mom      = 'Betty'
    Daughter = 'Janice'
    Son      = 'Bryan'
}

While hash tables have indexes, they’re non-numeric. Actually, I am not even sure I like the term index when working with hash tables. I suggest we call it what they are: keys. Maybe you noticed, but the order in which we created our hash table was not the order in which it was returned. A numeric value here would not help us anyway. Instead, we’re going to use the keys as our indexes to return our values.

$Hash02['Dad']
David
$Hash02['Daughter']
Janice

There is a good possibility that you are probably going to want to loop through and display all the values in your hash table. It’s a little out of place, but we’ll do that with one of our arrays here, too. Using the GetEnumerator() method allows us to get to the key and value, values out of our hash table. In this first, hash table example we are using the key and associated value in a string. This requires the use of the subexpression operator ($()), so that we can display our values within the string.

foreach ($Person in $Hash02.GetEnumerator()) {
    "The $($Person.Key) is $($Person.Value)."
}

The Son is Bryan
The Dad is David
The Mom is Betty
The Daughter is Janice

We are using the subexpression operator in the string created by looping over our array, too.

$Array05 = 'black','red','green','blue','brown'
foreach ($Color in $Array05) {
	"Is your favorite color $($Color)?"
}
Is your favorite color black?
Is your favorite color red?
Is your favorite color green?
Is your favorite color blue?
Is your favorite color brown?

This has been a lengthy post — who knew this would happen!? There is one last thing I want to mention, and that is about creating an ordered hash table, or dictionary. We tend to use the dictionary term when we order a hash table.

$Hash03 = [ordered]@{
    Monday    = 'Chipotle'
    Tuesday   = 'Pizza'
    Wednesday = 'Mahi Mahi'
    Thursday  = 'Ravioli'
    Friday    = 'Orange Chicken'
}
$Hash03

Name                           Value
----                           -----
Monday                         Chipotle
Tuesday                        Pizza
Wednesday                      Mahi Mahi
Thursday                       Ravioli
Friday                         Orange Chicken

Because this is ordered, we can use numeric indexes again. Keep in mind, however, that doing this is only going to return the values and not the keys, as well. It may even momentarily confuse you into thinking this is an array, not a hash table, or an associative array. Maybe stick to using a foreach at this point. Do not forget the GetType() method to ensure you know your data structures.

$Hash03[0..4]
Chipotle      
Pizza
Mahi Mahi     
Ravioli       
Orange Chicken

$Hash03.GetType()
IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------     
True     True     OrderedDictionary                        System.Object

Okay, I am stopping here. There’s plenty to know about these two data structures, and at this point, it is more than I’m willing to share. Even so, this should provide a decent breakdown to go along with the Microsoft documentation and other information that’s available to consume on this topic. Know what you are talking about.

Setting the Rounding Scale

Sometimes sharing one concept in a post, allows you to share another concept in another post. That brings us to today. This is that other post.

Originally, I had a great title for this post: It was Rounding Precision Decision. Then, for whatever reason, I went and made sure that precision was the word I was after. It wasn’t. Precision is the total number of digits in a number. Scale is the number of digits after the decimal.

Last night I decided I should add a Round parameter to a function I’m writing. This would allow the user to determine how rounding should be applied to a given number. The parameter values, as I see them now, will be 0 through 4. This is to say a numerical value may have zero decimal places up to four, depending on the person/process running the function. Neat, right? Like I sometimes do, I opened Window Terminal to start some one-off testing.

Let’s start with an ordered hash table of numeric values. As you’ll see, the values will vary in the number of decimal places from zero to five.

[PS7.1.5][C:\] $Hash = [ordered]@{'Num0' = 42; 'Num1' = 42.1; 'Num2' = 42.12; 'Num3' = 42.123; 'Num4' = 42.1234; 'Num5' = 42.12345}
[PS7.1.5][C:\] $Hash

Name               Value
----               -----
Num0               42
Num1               42.1
Num2               42.12
Num3               42.123
Num4               42.1234
Num5               42.12345
[PS7.1.5][C:\] 

While we’re here, let’s loop through the keys and values in this hash table. We’ll need this construct soon enough anyway.

[PS7.1.5][C:\] Foreach ($Key in $Hash.Keys) {"$Key`: $($Hash[$Key])"}
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
[PS7.1.5][C:\] 

That works. Now what we need to consider is that we’re going to need to iterate over $Hash multiple times, so we can apply each of the decimal values, 0 – 5 for this post. This may be confusing, but the next example should help explain how we get there.

[PS7.1.5][C:\] Foreach ($Value in 0..5) {$Value}
0
1
2
3
4
5
[PS7.1.5][C:\] Foreach ($Value in 0..5) {Foreach ($Key in $Hash.Keys) {"$Key`: $($Hash[$Key])"}}
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
[PS7.1.5][C:\]

Now that we have this working, let’s apply some rounding to each of the sets of numbers. Before we do that, however, I’m heading back to VSCode. Sometimes the one-off code I write gets a bit unwieldy. For reference, we’re going to use the Round method in the System.Math class, such as [math]::Round(<number>,<scale>).

$Hash = [ordered]@{
	'Num0' = 42
	'Num1' = 42.1
	'Num2' = 42.12
	'Num3' = 42.123
	'Num4' = 42.1234
	'Num5' = 42.12345
}
Foreach ($Value in 0..5) {
	"Rounding to $Value"
	Foreach ($Key in $Hash.Keys) {
		"$Key`: $([math]::Round($Hash[$Key],$Value))"
	} # End Foreach.
'--separator--'
} # End Foreach.

Rounding to 0
Num0: 42
Num1: 42
Num2: 42
Num3: 42
Num4: 42
Num5: 42
--separator--
Rounding to 1
Num0: 42
Num1: 42.1
Num2: 42.1
Num3: 42.1
Num4: 42.1
Num5: 42.1
--separator--
Rounding to 2
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.12
Num4: 42.12
Num5: 42.12
--separator--
Rounding to 3
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.123
Num5: 42.123
--separator--
Rounding to 4
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.1234
--separator--
Rounding to 5
Num0: 42
Num1: 42.1
Num2: 42.12
Num3: 42.123
Num4: 42.1234
Num5: 42.12345
--separator--

At first glance, this PowerShell code may look like it’s failing. Look at the “Rounding to 3” section, for instance. There are values where it appeared to round to zero, one, and two decimal places. Remember though, these numbers didn’t start with three decimals places or more. It did exactly what we asked it to do to the best of its ability. I don’t know of a way that the Round method can add zeros if we actually wanted that — let me know if you — but there’s another way!

This time, we’ll use the -f format operator and force zeros into the decimals places. I probably won’t do this in my upcoming post, but I think it’s worth seeing, as there’s value here.

Foreach ($Value in 0..5) {
	"Rounding to $Value"
	Foreach ($Key in $Hash.Keys) {
		"$Key`: $("{0:N$Value}" -f $Hash[$Key])"
	} # End Foreach.
'--separator--'
} # End Foreach.

Rounding to 0
Num0: 42
Num1: 42
Num2: 42
Num3: 42
Num4: 42
Num5: 42
--separator--
Rounding to 1
Num0: 42.0
Num1: 42.1
Num2: 42.1
Num3: 42.1
Num4: 42.1
Num5: 42.1
--separator--
Rounding to 2
Num0: 42.00
Num1: 42.10
Num2: 42.12
Num3: 42.12
Num4: 42.12
Num5: 42.12
--separator--
Rounding to 3
Num0: 42.000
Num1: 42.100
Num2: 42.120
Num3: 42.123
Num4: 42.123
Num5: 42.123
--separator--
Rounding to 4
Num0: 42.0000
Num1: 42.1000
Num2: 42.1200
Num3: 42.1230
Num4: 42.1234
Num5: 42.1234
--separator--
Rounding to 5
Num0: 42.00000
Num1: 42.10000
Num2: 42.12000
Num3: 42.12300
Num4: 42.12340
Num5: 42.12345
--separator--

And that’s, that. Back to the other post that inspired this one. See you there in time!

Hash Table in Hash Table to JSON

Edit: It turns out that I did in fact go over nesting a hash table inside a hash table in Part II of my Splunk series. There’s still some likable and solid content in this post though.

It’s how it works. A single topic, or idea, or even a real live project, can lead to additional writing and posting. As many might recognize, I use my blog for at least two things. One, it’s a place for you and others to come and potentially learn something new. Or maybe it’s just to reinforce a concept. I do my best to make things quick and clear. Two, it’s. for. me. Sometimes I share something simply because I need a place to store it for my own reference. Every post I’ve written — and I’m getting close to 350 of them — serves both purposes. This one certainly does, too.

If you’ve been paying attention, you know I’m currently working with my function template (which I write as FunctionTemplate at work), gathering telemetry data, and posting that to Splunk via a REST endpoint. It’s been fascinating. I had wanted an opportunity to work with Splunk and lucky for me a colleague mentioned it, even though I was preparing to work with AWS. I’m grateful they did!

A part of working with Splunk and REST and HEC requires that a payload be sent in as JSON. Luckily, PowerShell includes a command to convert a hash table to JSON. As a part of this project, I’ve converted numerous strings and even an array to JSON. Take a look.

I got to thinking that I want my telemetry code to acquire the city, state, and country via the public IP address and a geolocation API. Although it started this way, I decided I didn’t want single strings in my JSON for each of the properties.

Therefore, I needed to create a hash table of the data (within the parent hash table), and then convert that to JSON. Yes, you heard that correctly, we’re going to nest a hash table inside of another hash table and convert that to JSON. You may remember something about this in the Splunk series. Well, we cover it all again, and all because I want my Location data inside a hash table and not as three single strings. In the end, the below explanations — most of it anyway — will get us to this image.

Let’s pretend my public IP address is 8.8.8.8. Much of the hey-sign-up text in the below response won’t be there if you’re using your own public IP address, as opposed to one of Google’s. I’d still recommend you take a look at the ipapi.co website and do your own due diligence regarding the API.

Once I knew how to obtain my geolocation data via ipapi.co, I could use the below code. In the code I create three hash tables:

  • TelemetryHash
  • TelemetryHashStandard
  • TelemetryHashLocation

The TelemetryHashStandard hash table holds two key-value pairs: DateTime and Directory (as in our location within the operating system). These aren’t vital for more than the inclusion of a couple of standard entries in the parent hash table. The TelemetryHashLocation hash table holds three key-value pairs: City, Region, and Country.

Once the values are obtained and stored in one of the two hash tables, we store TelemetryHashStandard in TelemetryHash. Then we add our TelemetryHashLocation hash table as a single key-value pair to the TelemetryHash hash table. Now that you’ve gotten through that reading, be sure to review the below code.

Remove-Variable -Name TelemetryHash,TelemetryHashStandard,TelemetryHashLocation -ErrorAction SilentlyContinue
New-Variable -Name TelemetryHash -Value @{}
New-Variable -Name TelemetryHashStandard -Value @{}
New-Variable -Name TelemetryHashLocation -Value @{}

$TelemetryHashStandard.Add('DateTime',"$(Get-Date)")
$TelemetryHashStandard.Add('Directory',"$((Get-Location).Path)")

$Location = Invoke-RestMethod -Uri "https://ipapi.co/8.8.8.8/json"
$TelemetryHashLocation.Add('City',$Location.city)
$TelemetryHashLocation.Add('Region',$Location.region)
$TelemetryHashLocation.Add('Country',$Location.country_name)

$TelemetryHash = $TelemetryHashStandard
$TelemetryHash.Add('Location',$TelemetryHashLocation)
$TelemetryHash | ConvertTo-Json

{
  "Location": {
    "Region": "California",    
    "Country": "United States",
    "City": "Mountain View"    
  },
  "Directory": "C:\\",
  "DateTime": "01/13/2021 19:33:14"    
}

See that; just above? There are the two single strings — DateTime and Directory — as well as the single Location hash table and its nested keys and values. And, just for fun, here’s another example. Here we create two hash tables: one for parents and one for children. Once they’re both populated, we add the children to the parents’ hash table. Like we did above, we could’ve gotten everything into a single hash table that was neither the parent’s or children’s hash table. All this to say, there’s no requirement for a third and final hash table needed prior to the JSON export.

[PS7.1.0] C:\> $Parent = @{}; $Child = @{}
[PS7.1.0] C:\> $Child.Add('Son','CM')
[PS7.1.0] C:\> $Child.Add('Daughter','AM')
[PS7.1.0] C:\> $Child

Name                           Value
----                           -----
Son                            CM
Daughter                       AM

[PS7.1.0] C:\> $Parent.Add('Father','Tommy')
[PS7.1.0] C:\> $Parent.Add('Mother','JM')
[PS7.1.0] C:\> $Parent

Name                           Value
----                           -----
Mother                         JM
Father                         Tommy

[PS7.1.0] C:\> $Parent.Add('Children',$Child)
[PS7.1.0] C:\> $Parent

Name                           Value
----                           -----
Children                       {Son, Daughter}
Father                         Tommy
Mother                         JM

[PS7.1.0] C:\> $Parent.Children

Name                           Value
----                           -----
Son                            CM
Daughter                       AM

[PS7.1.0] C:\> $Parent | ConvertTo-Json
{
  "Children": {
    "Son": "CM",
    "Daughter": "AM"
  },
  "Father": "Tommy",
  "Mother": "JM"
}

By nesting a hash table inside of another hash table, we can convert to JSON and maintain the data’s original structure. Add arrays and hash tables to the hash table you intend to convert/export to JSON, and they’ll be there just as you expect them to be.

Hash Table to CSV, Revisited

I started writing about PowerShell in June 2014 at tommymaynard.com. While I’m not a Microsoft MVP, I’m certainly working to obtain Microsoft’s longevity award. While the distinction doesn’t actually exist, this year will mark six consistent years of reading, researching, spending my time with PowerShell, and giving back to the community in my written word. With the combination of my site and this one, I’ve authored somewhere close to 350+ articles, or posts.

What I’m really out to say here, is that in my time, I’ve noticed which of my writings have been consistently popular. There’s a particular post on my site that sees the largest amount of consistent visitors: It’s Hash Table to CSV. I’ve been looking for a way to take its personal success and provide more to the reader about the topic. That’s what we’re doing today with this post. I put a link to the original post on Twitter recently, and someone provided me an idea for an update — whether they realized it or not. It’s simple, but whatever. As proven, those are sometimes the most popular posts.

Before we get back into this, let’s remember how this all started. It started here: Hash Table to CSV. It’s always been a popular post, but just in case you didn’t follow this over from PowerShell.org, then you need to know this is a forward movement on that 2018 article.

I was sitting around and wondered how to best get a hash table into a CSV file. Maybe it was for configuration; I still don’t recall. Well, my option wasn’t the only option, and so today I’ll pass along something someone on Twitter pointed out that I hadn’t considered myself. We can use [PSCustomObject], introduced in (Windows) PowerShell 3.0.

I’ve long used this to create custom objects for its speed and insertion order preservation (over New-Object), but it didn’t occur to make use of it when getting a hash table into a CSV. It does work, with less work, so let’s try it on. While I won’t show the previous option, revisit the first article on this topic to see the old way; here’s the new way. We’ll start with our previously used hash table.

$HashTable = @{
    Name = 'Tommy'
    StreetName = 'Vista Pl.'
    City = 'Tucson'
}

$HashTable
Name                           Value
----                           ----- 
Name                           Tommy
StreetName                     Vista Pl.
City                           Tucson

Once that’s populated, instead of using the hash table’s GetEnumerator method, we’ll use [PSCustomObject]. This converts each entry in our hash table into an object, and sends the object to the Export-Csv cmdlet. We get what we expect in our CSV file without the additional work scripted into the first hash table to CSV article from 2018.

[PSCustomObject]$HashTable |
    Export-Csv -NoTypeInformation -Path .\Desktop\NewHashToCsv.csv

And, that was it. Quicker, easier, and more likely to be remembered, long term.

Edit: It was pointed out to me that this didn’t produce the exact information in the CSV from 2018. Instead of having a Key and Value properties, it included a property/column for each of the hash table’s keys: Name, StreetName, and City. Honestly, I think I like this better, as it reminds me of what any command that returns objects in PowerShell would do for us. If I were to read it back into the host (via Import-Csv), my output from the operation would be more in line with what PowerShell commands produces anyway: objects with properties. Thank you for the observation, Mike!

Read-Host Prompt inside Hash Table

I’m working with Plaster and in doing so, have a few hash tables in my workspace. Suddenly, and out of nowhere, I had a thought: Can I put a Read-Host command, as the value of a key-value pair inside of a hash table? Yes, but before we get too far into this, here’s a simple hash table example without any Read-Host commands.

$Params = @{
    meal = 'lunch'
    food = 'Ramen'
    drink = 'Tea'
}
$Params

Name                           Value
----                           -----
drink                          Tea
food                           Ramen
meal                           lunch

Okay, that was simple: Choose a variable name, prefix it with a dollar sign, create the hash table structure as @{}, and then add key-value pairs as <key> = <value>.

Now, on to a Read-Host example. Read-Host is a cmdlet that can be used to interactively prompt a user for a value. It’s not always preferred, or the right to do, but there are times when it can be useful, and where its use is acceptable. In the next example, we’ll create a single key-value pair ourselves, then we’ll prompt the user for a value to assign to the Number key. As you will also determine, when prompted, the word “five” is entered, and sure enough, the entry ends up as the value for the Number key in our hash table.

Remove-Variable -Name Params
$Params = @{
    Color = 'red'
    Number = Read-Host -Prompt 'Enter spelled out number'
}
$Params
Enter spelled out number: five

Name                           Value
----                           -----
Number                         five
Color                          red

This example was one of those “can I do this moments?” Sure, I was able to return the $Params hash table with the correct value in the Number key after having been prompted for that value. This occurred, as the hash table was being defined and built. I didn’t even know if that would work, but now we both know that it does.

In the next example, we try something even more obscure, but as suspected, it doesn’t work. We first assign the Random key the value of a Read-Host prompt. As we’ve seen, that does work. Next, while still creating keys and values, we take the value assigned to the Random key in the $Params hash table and attempt to assign it to the Number key, as well. Again, this doesn’t work. As suspected, we can’t use the $Params hash table until it’s done being created. It’s not a shock, but it was worth a try, of course.

Remove-Variable -Name Params
$Params = @{
    DayOfWeek = 'Friday'
    Random = Read-Host -Prompt 'Enter spelled out number'
    Number = $Params.Random
}
$Params
Enter spelled out number: three

Name                           Value                                                                                                                             
----                           -----                                                                                                                             
Random                         three
Number
DayOfWeek                      Friday

Even if this did work, I’m not sure how this would ever really serve a purpose, but it’s always worth trying something even if doesn’t seem plausible. And if it did work, I don’t expect that we’d even need duplicate values in different keys anyway, and that’s all we’d be doing. But all that said, we absolutely can use Read-Host to assign a value to a key in a hash table, as it’s being created.

Alright, that was it. Enjoy the week!

Array (Not Hash Table) Splatting


Welcome to the 298th post on tommymaynard.com. It’s countdown to 300!


I’ve been interested… okay fine, consumed with PowerShell for five, maybe six years. At some point along the way, I learned how to splat. That’s where you create a hash table of keys and values (think parameters and parameter values), and include those when invoking a cmdlet or function. Here’s an example of not splatting, and splatting, a hash table.

Get-Process -Name firefox -FileVersionInfo -OutVariable FirefoxProcess

The above example shows how we might typically write this command. The below example uses splatting. To be more specific, it uses hash table splatting.

$Params = @{
    Name = 'firefox'
    FileVersionInfo = $true
    OutVariable = 'FirefoxProcess'
}
Get-Process @Params

Well today, many years since I started this journey, I find myself suddenly exposed to array splatting. Huh? You might be able to guess how this works. We’re still going to issue a command, and we’re still going to use the at sign (@) in front of our variable name, but this time, our variable is going to contain an array, not a hash table. Let’s take a look at a few more examples.

Get-ChildItem -Path '.\Documents\test\' -Filter '*.rtf'
Get-ChildItem '.\Documents\test\' '*.rtf'

In the first above Get-ChildItem example, you can see how we might typically issue this command. In the example below that one, we’re running the same above command; however, we’re doing so without including the Path and Filter parameter names. Because this still works, we know these two parameters are positional (or because we read the help first). This means they can be used correctly without the need to include their matching parameter names. Because they’re positional, we can use array splatting. Take a look at the final below example.

$Params = '.\Documents\test\','*.rtf'
Get-ChildItem @Params

Just a quick reminder. We should always use parameter names in code we expect to been seen, or used, more than once, such as code inside functions and scripts. It’s good to know about this, but it might be something to avoid. Using hash table splatting may still be the way to go, as it keeps our parameter names around.

An Array of Hash Tables


Welcome to the 293rd post on tommymaynard.com. It’s countdown to 300!


If you’ve ever looked into Pester and TestCases, then maybe you’ve seen what I’m about to mention. While today’s post has nothing to do with Pester, this feature in Pester uses an array of hash tables. Neat, right? While adding a couple New-PSDrive commands to my PowerShell profile, I moved from this first option,…

$Param = @{
    Name = 'IDT'
    Root = '\\tommymaynard.com\Windows\Internal\Users\tommymaynard'
}
New-PSDrive @Param -PSProvider FileSystem | Out-Null

$Param = @{
    Name = 'IDI'
    Root = '\\tommymaynard.com\Windows\Internal'
}
New-PSDrive @Param -PSProvider FileSystem | Out-Null

…to something else.

While the use of splatting is a bit more grown-up than creating long, multi-line wrapping commands, there’s no reason why we should be executing the same command — New-PSDrive, in this instance — outside of a looping construct. That was my thought today, anyway. If we need to invoke the same cmdlet or function more than once, it should only be entered into our code, once. It is possible there’s an exception here, but for the most, I stick to this belief.

But how do I combine multiple hash tables in to looping construct? Well, my solution had everything to do with my quick remembrance of Pester and TestCases. For fun, we’ll link to a quick example from a Pester issue I recently created in GitHub. This offers us a good example. See the third It block in the Pester example in number 4 (“Current Behavior”). Do you see that? It’s an array of hash tables. Perfect example for what I needed.

As we create our hash tables, we need to ensure they’re being added to an array. Then we can loop through our array elements with ForEach, or ForEach-Object. I’ll include examples for both. First, however, let’s create our array of hash tables.

$HashTableArray = @(
    @{
        Name = 'IDT'
        Root = '\\tommymaynard.com\Windows\Internal\Users\tommymaynard'
    },
    @{
        Name = 'IDI'
        Root = '\\tommymaynard.com\Windows\Internal'
    }
)

And now, let’s ensure what we have, is where we want it, and want we want.

PS > $HashTableArray

Name                           Value
----                           -----
Root                           \\tommymaynard.com\Windows\Internal\Users\tommymaynard
Name                           IDT
Root                           \\tommymaynard.com\Windows\Internal
Name                           IDI

As mentioned, there’s a couple way to loop though these. One is using a Foreach construct — which is the first below example — and one is using the ForEach-Object cmdlet. They’re both below, and listed in the respective order in which they were discussed. So yes, if you’re calling the same command outside of looping construct, you need to consider how to do better, if you can. There’s no reason in my instance that New-PSDrive should be in a our code more than once.

Foreach ($HashTable in $HashTableArray) {
    New-PSDrive @HashTable -PSProvider FileSystem | Out-Null
}

$HashTableArray | ForEach-Object {
    New-PSDrive -Name $_.Name -PSProvider FileSystem -Root $_.Root | Out-Null
}

If you didn’t notice, I’ve piped my New-PSDrive commands to Out-Null. This was done in order to remove the output that would’ve otherwise been produced.

Hash Table to CSV

Update: There’s a “part two” now. See the link at the bottom of this post.

I was sitting here, and I wondered, how do I get a hash table into a CSV? Have I even ever done that? Now, a few commands in, and I can’t even remember why I wondered that. There was a reason, I just wish I could remember what it was. Whatever it was, I should be more likely to remember how to get a hash table into CSV when I need it after today’s post. Was it on-disk storage for a hash table for some software configuration? Ugh, what was it?

Anyway, let’s start by assigning a hash table to a variable. Maybe it’ll come back to me.

$HashTable = @{
    Name = 'Tommy'
    StreetName = 'Vista Pl.'
    City = 'Tucson'
}

$HashTable
Name                           Value
----                           ----- 
Name                           Tommy
StreetName                     Vista Pl.
City                           Tucson

Now that we’ve assigned our $HashTable variable the value of our hash table, we can try and get it into a CSV. At first, someone might try the below option. Let’s see how that works.

$HashTable |
    Export-Csv -NoTypeInformation -Path .\Desktop\HashToCsv.csv

As you can see, this doesn’t work.

In order to get this to work properly, we need to use the GetEnumerator method. I seem to use this quite often. This allows us to walk through each key-pair in our hash table.

$HashTable.GetEnumerator() |
    Export-Csv -NoTypeInformation -Path .\Desktop\HashToCsv2.csv

Now it’s just perfect, minus the whole Name property (column). Huh? I only expected the Keys and Values, like we’d see produced onscreen. With this in mind, let’s instead pipe to the Select-Object cmdlet before Export-Csv and get things properly filtered.

Update: It dawned on me, after I made all these screen captures, that I wasn’t expecting to see the above Name property included. Sure, it holds the same values as Name, but in a host program, we’re actually accustomed to seeing Name and Value, not Key and Value.

$HashTable.GetEnumerator() |
    Select-Object -Property Key,Value |
        Export-Csv -NoTypeInformation -Path .\Desktop\HashToCsv3.csv

My next logical thought was, can we use calculated properties? Can I use a different descriptor than Key and Value? You bet we can — take a look.

$HashTable.GetEnumerator() |
    Select-Object -Property @{N='Property';E={$_.Key}},
    @{N='PropValue';E={$_.Value}} |
        Export-Csv -NoTypeInformation -Path .\Desktop\HashToCsv4.csv

So yeah, there we go. I can use a hash table, saved to disk, for … whatever reason. I still don’t remember why I wondered this originally, but in case it’s helpful, I know where to find this when I remember why I wondered.

Update: There’s a follow-up post now that includes an easier way.