Maybe this is an artifact of a generational divide, or with less generalization, a function of familiarity with tooling?

For their most basic requirement, a line-per-item format will suffice, and provides superior usability. You can edit it by hand, you can use all manner of widespread *nix-y userspace programs to manipulate the list or generate it dynamically, and it's dead simple to parse.

But if you've spent less time in that space, a canned 'configuration management' format sounds reasonably attractive, because it has well-defined semantics and you can build out your schema as you add more features without having to rip the underlying layer out.

Attractive as that may be, once you bring in a format whose syntax needs balanced markers, your editing usability goes down unless you use specialized tooling that can understand that format. This is one of many find YAML more palatable for this kind of task than JSON, why CSV will never die, and why INI is a surprisingly good configuration format.

TOML [1] took the best of INI and YAML, and is worth looking at as an alternative to JSON and YAML, while for batch ingestion of data, few things will beat the versatility of CSV. The one-record-per-line format can be implemented as one-column minimal form of CSV, so that it can still be extended later, if the need arises.

[1] https://github.com/toml-lang/toml

You are correct, that is the simplest way.

What did I not disclose in the article is that I also wanted somehow to name data.

I wanted this because I also know that in the configuration file, expect IP addressed I will also need to store sleep duration.

I just find it more articulated if I also have a name for data.

Now I use https://github.com/pasztorpisti/json-cfg for storing configuration as JSON. json-cfg has the ability to add comments to JSON file.

If you want to name your data, then you could have had a couple a different text files that were named differently

I meant data inside the text file.

Anyway, this is more question of preference :-)

I find plain csv a bit underrated in these kind of applications. As long as you have flat data, you can read and edit the file with practically anything without too much trouble.

I have several hundred sites that I need to ssh into and run commands on. I use a csv file with IP addresses, etc. So yeah, a simple text file should have been the developer's first thought if all they needed was IP addresses.

Or how about comma separated list of IPs in configparser format, that you then just split?

Just because the format doesn't support lists doesn't mean you need to make it parse [, ] etc on top.

then replace all the line breaks, <, < and single quotes with ","

split it on the double quotes(!?)

have some stupid ip validation like a minimum length and chars used (trim included ofc)

and voilà! Now it parses line break or comma separated as well as json, xml, html. Can throw any crap at it, if the crap has anything that looks like ip addresses wrapped in quotes and or line breaks it will work.

Make the ip validation better for even better results.

The whole point is to not have to do all that extra work, because you make your input file format simple enough.

Just read a line, take the first (or only) whitespace-separated part and feed it to inet_addr() or whatever networking function you use that takes hostnames and uses them. If it's invalid, it will tell you and you can print the offending one. No need to do anything extra.

My experience has taught me that it's fragile and stupid to do any sort of "validation" by reimplementing parts of lower layers. Need IPv6 support, or hostnames instead of IPs? If you hardcoded validation for IPv4 only, then you have to do extra work to either add that duplication, or (even better) get rid of the code completely. If you let the lower layers do the work, the additional functionalty is free. (And if the data is invalid to the lower layer, it will complain for you.)