how to parse INI files ?

I want my program to parse INI files, only have little clue of how to do
that, though, hope you guys might shed some light on this, thanx.



for example:



[configuration]

admin=dreamcatcher



[variables]

var1=100

var2="string literal"

var3=0x4234

var4=1010101010101



[adaptor]

vga=Super VGA


--
Posted via http://dbforums.com

re: how to parse INI files ?

Use the GetPrivateProfileString API

re: how to parse INI files ?

dreamcatcher wrote:
[color=blue]
>
> I want my program to parse INI files, only have little clue of how to do
> that, though, hope you guys might shed some light on this, thanx.
> for example:
> [configuration]
> admin=dreamcatcher
> [variables]
> var1=100
> var2="string literal"
> var3=0x4234
> var4=1010101010101
> [adaptor]
> vga=Super VGA[/color]

(Whitespace stripped mercilessly)

Okay, as you can see, there's a sort of grammar here. Let's see how I do:

INI-file:
section
section INI-file

section:
section-title var-list

section-title:
'[' section-identifier ']'

section-identifier:
a sequence of characters not including ']'

var-list:
var-value-pair
var-value-pair var-list

var-value-pair:
variable '=' value

variable:
a sequence of characters not including '='

value:
a sequence of characters terminating in a newline character



I think I got that right. Implement that language, and you're laughing.



--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

re: how to parse INI files ?

jacob navia wrote:
[color=blue]
>
> Use the GetPrivateProfileString API[/color]

There is no such function or API in C.

--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

re: how to parse INI files ?

"dreamcatcher" <member39454@dbforums.com> wrote in message
news:3523905.1067157172@dbforums.com...[color=blue]
>
> I want my program to parse INI files, only have little clue of how to do
> that, though, hope you guys might shed some light on this, thanx.[/color]

You could trivially write a hand-written parser for these. You just need to
actually do your homework.

Tom

re: how to parse INI files ?

Learn to use a search engine like Google!

Just starting a search with "parse ini file c" gives you one good hit
on the first result page:
http://c.snippets.org/snip_lister.php?fname=ini.c

re: how to parse INI files ?

dreamcatcher wrote:[color=blue]
> I want my program to parse INI files, only have little clue of
> how to do that, though, hope you guys might shed some light on
> this, thanx.
>
> for example:
>
> [configuration]
> admin=dreamcatcher
>
> [variables]
> var1=100
> var2="string literal"
> var3=0x4234
> var4=1010101010101
>
> [adaptor]
> vga=Super VGA[/color]

Dreamcatcher...

There are three aspects to this problem:

1. Input and parse each line
2. Save the information in some usable form
3. Access the information as needed

(1) isn't too difficult
(2) is easily handled by building a linked list of sections;
and by attaching a list of key/value structures to each
section.
(3) is most easily handled by writing a set of functions
like:

find_section()
next_section()
find_key()
next_key()

I found it helpful to provide a [Global] section (the name isn't
particularly significant) under which any key=value entries
preceeding the first named section are linked. If there are no
such entries, then I don't provide the [Global] section element.

You may also find it helpful to provide for comment lines and/or
end of line comments to make the .ini file more readable and
maintainable.

I also added the ability to have lines of text in the file (in
addition to key=value lines); and am playing with adding CSV data
lines.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall very far from the tree.

re: how to parse INI files ?

Greetings.

In article <bngbe7$hru$1@titan.btinternet.com>, Richard Heathfield wrote:[color=blue]
> Okay, as you can see, there's a sort of grammar here. Let's see how I do:
>[/color]
[snip][color=blue]
>
> I think I got that right. Implement that language, and you're laughing.[/color]

Though the language is simple enough as it is, lex and yacc (or flex and
bison) would speed development here. In just a few minutes you'll get a
shiny new INI file parser written specially for you in ANSI C.

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

re: how to parse INI files ?

Morris Dovey wrote:[color=blue]
> dreamcatcher wrote:
>[color=green]
>> I want my program to parse INI files, only have little clue of
>> how to do that, though, hope you guys might shed some light on
>> this, thanx.
>>
>> for example:
>>
>> [configuration]
>> admin=dreamcatcher
>>
>> [variables]
>> var1=100
>> var2="string literal"
>> var3=0x4234
>> var4=1010101010101
>>
>> [adaptor]
>> vga=Super VGA[/color]
>
>
> Dreamcatcher...
>
> There are three aspects to this problem:
>
> 1. Input and parse each line
> 2. Save the information in some usable form
> 3. Access the information as needed
>
> (1) isn't too difficult[/color]

ACtually, there are many pitfalls:

(1) What of duplicate sections?

(2) What of duplicate keys?

(3) What of space before/after, the key/the value?

(4) Is order significant? Should it be maintained?

(5) What of KVPs outside a section? A proposal was made by Morris
(below), but it is not the only possible one, one could ignore them with
or without warning.

(6) What of lines not conforming to K=V? Here again a proposal is made
by Morris, but is it the best? Maximal compatibility with MS-Windows
could be a design goal.
[color=blue]
> (2) is easily handled by building a linked list of sections;
> and by attaching a list of key/value structures to each
> section.[/color]

I would rather use B-tree of sections, with B-tree of key/value pairs,
plus hased keys for fast comparisons.
[color=blue]
> (3) is most easily handled by writing a set of functions
> like:
>
> find_section()
> next_section()
> find_key()
> next_key()[/color]

A stateful API. Yuck.
[color=blue]
>
> I found it helpful to provide a [Global] section (the name isn't
> particularly significant) under which any key=value entries preceeding
> the first named section are linked. If there are no such entries, then I
> don't provide the [Global] section element.
>
> You may also find it helpful to provide for comment lines and/or end of
> line comments to make the .ini file more readable and maintainable.
>
> I also added the ability to have lines of text in the file (in addition
> to key=value lines); and am playing with adding CSV data lines.[/color]


--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41

re: how to parse INI files ?

Michel Bardiaux wrote:
[color=blue]
> Morris Dovey wrote:[/color]
[color=blue][color=green]
>> There are three aspects to this problem:
>>
>> 1. Input and parse each line
>> 2. Save the information in some usable form
>> 3. Access the information as needed
>>
>> (1) isn't too difficult[/color][/color]
[color=blue]
> ACtually, there are many pitfalls:
>
> (1) What of duplicate sections?[/color]

I treated the second (and subsequent) duplicate section as an
(intended) continuation of the first.
[color=blue]
> (2) What of duplicate keys?[/color]

I allowed duplicate keys; and if the value associated with the
duplicate didn't duplicate an existing entry's in the current
section, created a new KVP entry for the current section. If the
application didn't like duplicate keys, /it/ could complain,
abort, etc.
[color=blue]
> (3) What of space before/after, the key/the value?[/color]

I strip leading and trailing spaces from section names, keys, and
values. When multiple spaces are found within section names and
keys, they are reduced to single spaces. Multiple spaces within
values are retained.
[color=blue]
> (4) Is order significant? Should it be maintained?[/color]

I maintained the order of /first instance/ of sections and KVPs
within each section. KVPs and text entries were kept in separate
lists. (BTW, this was my rationale for using linked lists.)
[color=blue]
> (5) What of KVPs outside a section? A proposal was made by Morris
> (below), but it is not the only possible one, one could ignore them with
> or without warning.[/color]

It struck me as perilous to silently discard configuration data;
and I preferred to have the application do any complaining. This
was my rationale for the "ghost" [Global] section.
[color=blue]
> (6) What of lines not conforming to K=V? Here again a proposal is made
> by Morris, but is it the best? Maximal compatibility with MS-Windows
> could be a design goal.[/color]

Well, I'd actually /wanted/ section-specific (multi-line) text,
so that's what I built in. Given that it supported a requirement
rather exactly, it /was/ the best solution. (But YMMV. 8-)

Given that I'm pretty much a POSIX bigot, I felt completely free
to improve on MS-anything (and they make it /so/ easy to do!)
[color=blue][color=green]
>> (2) is easily handled by building a linked list of sections;
>> and by attaching a list of key/value structures to each
>> section.[/color]
>
> I would rather use B-tree of sections, with B-tree of key/value pairs,
> plus hased keys for fast comparisons.[/color]

Ok by me. My .ini files were relatively small (under 24k); and I
wasn't too worried about one-time initialization overhead. Again,
YMMV.
[color=blue][color=green]
>> (3) is most easily handled by writing a set of functions
>> like:
>>
>> find_section()
>> next_section()
>> find_key()
>> next_key()[/color][/color]
[color=blue]
> A stateful API. Yuck.[/color]

Stateful, yes. Yuck? Beauty is in the eye of the beholder. The
code was quick, simple, and reliable. All told, the package took
less than two hours to design, code, and debug -- and I was on to
the actual application code. Production of a reliable major
application delivered considerably under budget and much ahead of
schedule made a very happy client, who found it beautiful! (BTW,
they particularly liked the extreme flexibility that the various
configuration files provided.)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall very far from the tree.

re: how to parse INI files ?

Morris Dovey wrote:[color=blue]
> Michel Bardiaux wrote:
>[color=green]
>> Morris Dovey wrote:[/color]
>
>[color=green][color=darkred]
>>> There are three aspects to this problem:
>>>
>>> 1. Input and parse each line
>>> 2. Save the information in some usable form
>>> 3. Access the information as needed
>>>
>>> (1) isn't too difficult[/color]
>>[/color]
>[color=green]
>> ACtually, there are many pitfalls:
>>
>> (1) What of duplicate sections?[/color]
>
>
> I treated the second (and subsequent) duplicate section as an (intended)
> continuation of the first.
>[color=green]
>> (2) What of duplicate keys?[/color]
>
>
> I allowed duplicate keys; and if the value associated with the duplicate
> didn't duplicate an existing entry's in the current section, created a
> new KVP entry for the current section. If the application didn't like
> duplicate keys, /it/ could complain, abort, etc.
>[color=green]
>> (3) What of space before/after, the key/the value?[/color]
>
>
> I strip leading and trailing spaces from section names, keys, and
> values. When multiple spaces are found within section names and keys,
> they are reduced to single spaces. Multiple spaces within values are
> retained.
>[color=green]
>> (4) Is order significant? Should it be maintained?[/color]
>
>
> I maintained the order of /first instance/ of sections and KVPs within
> each section. KVPs and text entries were kept in separate lists. (BTW,
> this was my rationale for using linked lists.)
>[color=green]
>> (5) What of KVPs outside a section? A proposal was made by Morris
>> (below), but it is not the only possible one, one could ignore them
>> with or without warning.[/color]
>
>
> It struck me as perilous to silently discard configuration data; and I
> preferred to have the application do any complaining. This was my
> rationale for the "ghost" [Global] section.
>[color=green]
>> (6) What of lines not conforming to K=V? Here again a proposal is made
>> by Morris, but is it the best? Maximal compatibility with MS-Windows
>> could be a design goal.[/color]
>
>
> Well, I'd actually /wanted/ section-specific (multi-line) text, so
> that's what I built in. Given that it supported a requirement rather
> exactly, it /was/ the best solution. (But YMMV. 8-)
>
> Given that I'm pretty much a POSIX bigot, I felt completely free to
> improve on MS-anything (and they make it /so/ easy to do!)[/color]

I was taking exception to the idea that parsing was "relatively easy"; I
see you've pretty much covered all the bases. Even though I disagree
with most of your design decisions - I disallow duplicate sections,
duplicate keys, out-of-section keys, and order is neither relevant nor
maintained; and MSW compatibility *was* an important point, because we
do have customers who want MSW applications. The important issue is not
what choices are made, but that they are made at all and fully documented.
[color=blue]
>[color=green][color=darkred]
>>> (2) is easily handled by building a linked list of sections;
>>> and by attaching a list of key/value structures to each
>>> section.[/color]
>>
>>
>> I would rather use B-tree of sections, with B-tree of key/value pairs,
>> plus hased keys for fast comparisons.[/color]
>
>
> Ok by me. My .ini files were relatively small (under 24k); and I wasn't
> too worried about one-time initialization overhead. Again, YMMV.[/color]

We have strongly optimized access to the .INI; then it becomes practical
to look them up when needed, rather than writing all the data structures
needed to keep the information in-core.
[color=blue]
>[color=green][color=darkred]
>>> (3) is most easily handled by writing a set of functions
>>> like:
>>>
>>> find_section()
>>> next_section()
>>> find_key()
>>> next_key()[/color]
>>[/color]
>[color=green]
>> A stateful API. Yuck.[/color]
>
>
> Stateful, yes. Yuck? Beauty is in the eye of the beholder. The code was
> quick, simple, and reliable.[/color]

A POSIX bigot using an API modelled on FindFirst/FindNext? :-)
[color=blue]
> All told, the package took less than two
> hours to design, code, and debug -- and I was on to the actual
> application code. Production of a reliable major application delivered
> considerably under budget and much ahead of schedule made a very happy
> client, who found it beautiful! (BTW, they particularly liked the
> extreme flexibility that the various configuration files provided.)[/color]


--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41