Powershell: ConvertFrom-Ini, ConvertTo-Ini

[timoline]

Summary of the new feature/enhancement

It would be great if the following cmdlets are provided by default

• ConvertFrom-Ini
• ConvertTo-Ini

These cmdlet needs to convert ini from and to a psobject

example system.ini

; for 16-bit app support
[386Enh]
woafont=dosapp.fon
EGA80WOA.FON=EGA80WOA.FON
EGA40WOA.FON=EGA40WOA.FON
CGA80WOA.FON=CGA80WOA.FON
CGA40WOA.FON=CGA40WOA.FON

[drivers]
wave=mmdrv.dll
timer=timer.drv

[mci]

expected output

 Get-Content "c:\windows\system.ini" | ConvertFrom-Ini | fl

386Enh  : @{woafont=dosapp.fon; EGA80WOA.FON=EGA80WOA.FON; EGA40WOA.FON=EGA40WOA.FON; CGA80WOA.FON=CGA80WOA.FON; CGA40WOA.FON=CGA40WOA.FON}
drivers : @{wave=mmdrv.dll; timer=timer.drv}

[iSazonov]

Can you add a reference to Ini schema?

[timoline]

https://en.wikipedia.org/wiki/INI_file

[vexx32]

Looking at this section it seems pretty clear that a well-defined schema doesn't really exist, and such a cmdlet will most likely be required to figure out which of the variants is being used when parsing the file.

[iSazonov]

There is no standard such as RFC we can not implement these cmdlets for all platforms (being portable).

Also modern config files usually use JSON, YAML or XML not Ini.

[timoline]

There is no standard such as RFC we can not implement these cmdlets for all platforms (being portable).

Also modern config files usually use JSON, YAML or XML not Ini.

Funny you say this and I agree with you....
but currently Windows is still using these kind of config files...

[iSazonov]

currently Windows is still using these kind of config files

Yes, only new cmdlets must be portable.
I believe INI files can be easily parsed by a PowerShell script.

[timoline]

Sure it can be done by a powershell script.
But if Windows is still using these kind of INI's, powershell should support it by default.

Registry and all kind of other Windows only features are supported....it doesn't make sense to not implement this from an user perspective

[iSazonov]

Related #7542

@DarwinJS @mklement0 Perhaps you can add more about perspectives of INIs on Windows and Unix-s.

[DarwinJS]

Sure.

I have been doing software deployment on both of these systems for well over a decade.

Here is a good overview and proof of fairly extensive linux support: https://en.wikipedia.org/wiki/INI_file. It accurately points out Microsoft's steering away from them when the registry came about.

The INI file "schema" drifted a lot by incorrect usage of developers when they needed to get creative for things it did not handle well (which is why OS/2's registry was brought forward into Windows NT).

You can get a sense for it by analyzing the apis - to see the APIs, search for "PrivateProfile" from this page: https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getprivateprofilestringa

Interestingly, now with Microsoft getting OpenSSH running on Windows, we regress to the stone age by configuring it with a CONF file.

While INIs weren't great - CONF files are a huge antipattern - including for security.

Since they do not enforce any type of structure they must be parsed with RegEx's - which opens up a lot of risk that a desired locked-down configuration won't be applicable to all systems and relies on the skill of every individual automator to make something that is both incisive and comprehensive.

Due to this risk, most automators end up simply replacing the whole file - including with configuration management systems like chef, puppet, ansible, powershell DSC, etc, etc.

The problem with doing that is that it is the perspective of a fresh system setup. Wiping out existing configurations on existing in-place systems for a new "default" can cause many problems in large environments where more than one mechanism many need to manage these files or some of their values may need to be user editable and persisted for non-security concerning settings.

So while I thought I could have no more hate for INI files - I embrace them with love compared to CONF files. ;)

If it were up to me - OpenSSH would optionally support an INI file and have it as the authoritative configuration if present. Those who prefer the much less manageable and less secure CONF file could still use it by making sure an INI does not exist.

So I would say that not only is there a historic case for supporting them - they are eons ahead of the structureless CONF files that are so prevalent on Linux.

[kilasuit]

Whilst I understand the request, this to me is just another https://github.com/PowerShell/PowerShell/issues/3607 and I will point you to this comment in that issue https://github.com/PowerShell/PowerShell/issues/3607#issuecomment-458306488 and also this prior comment from @SteveL-MSFT https://github.com/PowerShell/PowerShell/issues/3607#issuecomment-457296230

I personally have very little use for Ini or yaml files so to have this boxed into Pwsh seems a waste for me

The direction that the PSTeam are looking at is to publish a meta module to the PowerShell Gallery that can be used by those that need it and are looking for suggested items in this Issue https://github.com/PowerShell/PowerShell/issues/7542 which ties in with their ideas for this https://github.com/PowerShell/PowerShell/issues/5681 - which I think is the right way to go about it going forward

[lzybkr]

While ini files are less popular today, toml (roughly a superset of ini) has seen significant adoption in the Rust community and has gained the attention of some .Net folks, e.g. Tomlyn.

I think it would be useful to have with toml support and add some restrictions when converting to/from ini. That said, I'm not sure it belongs in the core of PowerShell.

[ChadMcCaffery]

As it happens, I wrote scripts a few years ago that convert .ini & .inf files into objects. For .ini files, it produces a hashtable, because some section names can contain characters that cannot be converted to properties. I added them here: https://github.com/ChadMcCaffery/MiscPowershell.

[kvprasoon]

Wouldn't ConvertFrom-String help here rather than having a cmdlet ?

[vexx32]

ConvertFrom-String was never bundled with PS Core. ConvertFrom-StringData is available, but behaves a bit differently. You could potentially use it for simple INI files, but it wouldn't be able to handle the section headers or anything more complex.

[mklement0]

Support for TOML would definitely make this desirable _cross-platform_ functionality.

In the meantime, the 3rd-party PSIni module seems to be a popular choice, available from the PowerShell Gallery; you can see it in action in this Stack Overflow answer. Caveat: There is _no data-type support_:

• on writing to an INI file, .ToString() serialization is applied
• on reading, everything is read _as a string_.

---

As for in-box vs. download on demand:

I think what matters in the end is to have officially maintained or endorsed and curated functionality - whether maintained by the core team or by the community.

From a pure convenience perspective, having everything in-box is great, but obviously unrealistic.

The next best thing is (a) knowing that an official solution exists that is (b) easily discoverable and (c) easily installable on demand (and I think Install-Module qualifies).

[FireInWinter]

I think it should be in box for this. It is used as part of Windows and is a big hole in PowerShell OS coverage. I'm also worried about a very small module not being maintained very well. If it is maintained by the core team, then bugs will be addressed with other core items. I looked at PSIni and it seems to have some rather large issues still, bad enough that I would rather use my own homegrown parser for it.