Talk:Read a configuration file: Difference between revisions

From Rosetta Code
Content added Content deleted
m (→‎"Standard": language specific?)
(→‎"Standard": Agreed.)
Line 23: Line 23:
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. —[[User:Kevin Reid|Kevin Reid]] 18:49, 16 February 2011 (UTC)
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. —[[User:Kevin Reid|Kevin Reid]] 18:49, 16 February 2011 (UTC)


Agreed. My inclination would be to use INI as being more "language neutral".--[[User:Tikkanz|Tikkanz]] 20:00, 16 February 2011 (UTC)
: Agreed. My inclination would be to use INI as being more "language neutral".--[[User:Tikkanz|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" --[[User:Jofur|<Jofur>]] 20:11, 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" --[[User:Jofur|<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. --[[User:Short Circuit|Michael Mol]] 20:23, 16 February 2011 (UTC)

Revision as of 20:23, 16 February 2011

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)