More Fun with String Properties

The other day I posted an article about converting string properties that you might get from running a command line tool into a PowerShell named property. I was continuing to experiment with it. Here’s some code on how I could use it.

I end up with output like this:

It would be nice to clean up the values and remove non word characters like the “<“. But I wouldn’t want to remove the period from the image property. So I came up with this:

Each data element is cleaned up using the Replace operator to replace any character in the regular expression pattern with nothing. Then I started experimenting with command line output that display as a series of lines like ipconfig /displaydns. First, I have to decide what to process so I want to get all lines that have ‘. . .’ in it.

Looking at the output I can see that basically I get an “object” for every group of 5 lines.

This code counts in groups of 5 and gets each group of elements using a range of index numbers. Each line in the range is then split into 2 strings on the first : character. The first item will be the property name which is converted into a string property and the second item will be the data. This gives me a custom object:

Which lead to the next challenge. The last line is being interpreted as two separate properties which is a bit of a mess. So I need a way to rename that line. Or actually any line. Maybe instead of TimeToLive I want to use TTL. Here’s the next step.

I have to know in advance what line number each property will be on. But since I do I’ll create a hashtable that uses the line number (starting at 0) as the key. The hashtable value will be the replacement property name. In my process scriptblock I’m keeping track of how many lines I’ve worked on. If the counter matches a key in the hashtable I do a replacement. Now I get this:

At this point I recognize that I have another repeatable code that I could turn this into a function.

This function relies on Convert-StringProperty. At some point I should package this and few other things I have into a module. But for now you’ll have to make sure the other function is loaded into your shell. The default processing assumes you have tabular output like you get from arp -a. You can specify input that is in a list but then you also need to specify how many lines are grouped together. You can also specify a hashtable of replacement property names for either input type. To keep things easier, the hashtable keys start counting at 1.

You can’t pipe into the command. You have to specify the input like this:

convert-clioutput-1

Here are some other examples using tabular output including a property rename.

convert-clioutput-2

Using my IPCONFIG example from earlier, here’s I can do it with my new function.

In the grid view I can further filter or sort.

convert-clioutput-3

One remaining issue here is that everything is a string. But in that regard it really isn’t that much different than when you import a CSV file. I guess this gives me something else to work on. In the meantime, try this out and let me know what you think.

5 Replies to “More Fun with String Properties”

  1. This is very handy and i like that it handles tables or lists!
    For list handling, in the case of ipconfig /displaydns, I had to add a TrimEnd call to get rid of the trailing breadcrumbs ( . . . . . ) that follow the property names:
    #TrimEnd in case list has lines like:
    # Record Name . . . . . : shop.quest.com
    #in which case $split[0] would be:
    # Record Name . . . . .
    $prop = $split[0].TrimEnd(” \.”) | Convert-StringProperty -Delimiter $delimiter

    1. Actually, you should not have had to do that. If you are using my Convert-StringProperty function that happens automatically.

  2. Isn’t Convert-StringProperty designed to simply eliminate spaces from property names and format in camel case?
    With raw data such as this from ipconfig /displaydns:
    Record Name . . . . . : shop.quest.com
    the full string to the left of the colon is piped to Convert-StringProperty,
    and I get back:
    RecordName…..
    when I was expecting
    RecordName

    1. That is exactly what it supposed to happen. I checked what I posted and wouldn’t you know, I made changes locally to fix that problem but didn’t update the posted code. Go back and grab the updated Convert-StringProperty function and it should now work better.

Comments are closed.