Last weekend I decided I needed to improve my Powershell scripting skills for a technical training I’m attending this week and started working on a script that could download, install and configure several applications unattended on demand. More on that script in a later blog post, for now I will focus on a specific feature I needed to script in order to make it all work.
One of the applications was still using a .ini file to configure some parameters of the tool and by nature of the script, I wanted to modify these values. One could use a search & replace method to change values in a .ini file (which is of course a simple text based file). In my search to easily parse a .ini file, I found several functions that could read the file and insert the values into hashtables. This makes values usable in a variable like $inihash[sectionname][keyname] = “value” however due to the nature of hashtables, it will sort the values in it’s hashtable by the hashvalue of it’s content. As most of us know, a hash value is different per object, per runtime, per system and will generate a unsorted mess. Inserting a .ini file with key1, key2, key3 might end up as key2, key1, key3 and there is no real way to circumvent this.
I was trying to work out the solution by working with hashtables, arrays and more .net objects in order to store the .ini values in a neat and sorted way. One could make a array with a hashtable with another nested array and hashtable but this would greatly increase complexity and reduce code friendliness as the $ini[section][key] notation would no longer function.
The other day I was casually discussing the problem with a fellow trainee and he suggested to (ab)use a XML object as a “storage box” as it would neatly allow nested constructions (section.key = value) and will remain sorted as it was imported (1,2,3 –> 1,2,3). First we would have to import a .ini file in to a XML object, later modify values and finally export the XML to a .ini file (sorted like the input .ini file).