Talk:Read a configuration file

current task

Ok, so we currently have a task here without any implementation. But I find it odd that we are supposed to set a value based on the contents of a comment in a config file. In properly factored code I would imagine that either [a] you set the defaults before the config file is read, and/or [b] you explicitly declare non-false boolean values. (I am also a bit wary about the use of the term "standard" in that config file's comment.) --Rdm 22:28, 10 February 2011 (UTC)

Java properties files are closer to a de facto "standard", especially if you ignore the property substitution feature. Failing that, there's the old INI format. –Donal Fellows 22:59, 10 February 2011 (UTC)

How about modifying the task be the reading of a "simple" ini file that contains:

<lang ini>

Here we go...

[my_section]

Blah=blah

ab=1.234 [her_section]

ab=xyz

bc=C:\a\b\d.txt ab=release </lang>

And print the resulting information? I would think that variants of .ini files are in common use, and the current task example is odd in having two comment characters, #; one of which ';' seems to be ignored and a value returned for seedsremoved; also the file has uppercase identifiers that are returned as lowercase variables? Too much magic! --Paddy3118 03:59, 11 February 2011 (UTC)

The task says to ignore comments. So I wrote a Ruby example that ignores the '; SEEDSREMOVED' line and then prints 'seedsremoved = false' because it never found a 'SEEDSREMOVED' line. I suspect that the task is a draft because the author wants to decide what else to put in the config file. --Kernigh 04:41, 11 February 2011 (UTC)

"Standard"

I would like to see a statement of exactly how this configuration file format is “standard”, or the removal of the “standard” wording. Or, parsing a more “standard” (well-known) config file format such as Java properties or INI. —Kevin Reid 18:49, 16 February 2011 (UTC)

Agreed. My inclination would be to use INI as being more "language neutral".--Tikkanz 20:00, 16 February 2011 (UTC)

It would probably be better to formulate similar as "read a config file according to your language standard, extra credit for INI, Java property and XYZ" --<Jofur> 20:11, 16 February 2011 (UTC)

Agreed as well. I'd also be interested in seeing if there are configuration formats which can be parsed based on run-time-consumable grammar definitions. --Michael Mol 20:23, 16 February 2011 (UTC)

This was very similar to the .INI format, before the boxed section headers were introduced. I developed that into a brief specification entitled "Standard Configuration File Format" which I wrote back in 1991.

The reason for the two comment symbols is that the hash symbol is a permanent comment and cannot be manipulated automatically. However, a leading semicolon may be removed or placed by automatic software reconfiguration tools.

A related task to this one, which I have not yet written up is to comment out or uncomment one of the parameters.

Markhobley 00:47, 21 February 2011 (UTC)

In that case, where is the documentation link to the formal description of what the spec is? A standard isn't a standard unless people agree on it. That's the whole of what defines a standard, and I can assure you that people only really agree on defined versions of documents. (I used to work in standardization, so I know what's involved. It's a long long slog to do it for real.) –Donal Fellows 17:14, 24 April 2011 (UTC)

On orginal parser implementations, comments were completely ignored. I went for option [a] set defaults before the config file is read. Boolean values were initially set to false unless toggled to true by the parser. There was no magic to uppercase / lowercase and variable names not matching the option names. I simply converted the case of the option name to upper case, and in the match code, I simply placed the matched data into the variable that I required.

Markhobley 00:15, 28 February 2011 (UTC)

I take it you're not dealing with configuration parameters with commas in? (So far as I can see, they're always handled as sequence separators. Significant leading and trailing space would be another issue.) –Donal Fellows 17:18, 24 April 2011 (UTC)