Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 May 2000 03:10:11 -0400
From:      Garance A Drosihn <drosih@rpi.edu>
To:        boshea@ricochet.net, A G F Keahan <ak@freenet.co.uk>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Generic config file parser?
Message-ID:  <v04210113b557b8819553@[128.113.24.47]>
In-Reply-To: <20000528175415.Z337@beastie.localdomain>
References:  <3931B325.BB166270@freenet.co.uk> <20000528175415.Z337@beastie.localdomain>

next in thread | previous in thread | raw e-mail | index | archive | help
At 5:54 PM -0700 5/28/00, Brian O'Shea wrote:
>You are right, this could be done, but I wouldn't call it
>trivial.  I've always come to the conclusion that the interface
>to something like this would have to be kind of complex in order
>to keep it generic enough to be really useful.  For instance,
>there isn't one standard Unix config file format.  Do you want
>to build into it some of the different [commonly used] formats?
>If so, who defines these formats?  [...etc...]
>
>All of this is managable, it just seems like more trouble than
>it's worth. (but if you write it, I'll probably use it! ;)

For what it's worth, a long time ago and in a operating system
far away, we had something called "command language parser".
It was meant for parsing things more complicated than simple
options on a standard unix command-line, but not complicated
enough to pull out lex & yacc.  As the sun was setting on that
operating-system empire, it was rewritten in C, and then lost
track of...

I recently tracked down the author and picked up a more recent
copy of the C version.  There are licensing issues which were
left in limbo, so I can't just give it out without checking
with him.  Still, it could have easily handled the kind of
config file you're talking about.  While you'll have to do some
guessing as to what the following means, it's almost good enough
to parse the example for:

>   [SECTIONNAME1]
>   wibble1 = blah
>   wibble2 = 35
>   wibble3 = "a string that has more than one word"
>   ; this is a comment -- ignored
>   wibble4 = 4.567e9

// - - - - - - - start of example clparser code
procedure myactions for all;

terminal <id> is 1 to 100 of "ABCDEFGHIJKLMNOPQRSTUVWXYZ_1234567890";
terminal <int> is 1 to 15 of "1234567890";
terminal <arb> is 1 or more characters;
terminal <opt_sp> is 1 or more of " \t";
<sep> is <opt_sp> "=" <opt_sp>;
<float> is <int> @SaveInt ( "." ( <int> @SaveDecInt ) ) @SaveFloat;

goal <cline>
      is "[" <id> @SaveTerm "]" @SetSection
      or "wibble1" <sep> <id> @SaveTerm @SetW1
      or "wibble2" <sep> <int> @SaveInt @SetW2
      or "wibble3" <sep> <qstring> @SaveStr @SetW3
      or ";" <arb>   // Just ignore, do nothing...
      or "wibble4" <sep> <float> @SaveFloat @SetW4;

terminal <Nonq> is 1 or more excluding """";
<qstring> is """" @InitStr (<str_seg>)... <e_qstr>;
<str_seg> is <Nonq> @String_Seg_1
           or """""" @String_Seg_2    // embedded double quote
           ;
<e_qstr>  is """"
           or @Invalid_Qstring;       // must at be end of line

// - - - - - - - end of the example code

Clparser has two pieces.  The first you can think of as a
compiler, which will read in the above source and spit out
an include file and an "object" file (which is just a lot
of tables).  The second part is clplib, which is what you
link your program to.

The '//' starts a comment line (in clpgen).  '@xxx' means
call procedure 'myactions' (which was specified in the first
line) with the semantic action named 'xxx', where the C-value
for 'xxx' will be defined (enum'ed?) in the include library
that clpgen will generate.  You'd use the semantic action in
a switch() statement.  Something like 'SaveInt' would call a
routine in clplib to pick up the character string ("terminal")
just matched, and know how to turn that into an integer which
it would save away somewhere for some other action to pick up.

What I have there is cut & pasted from some examples, and I'm
sure it's not quite right.  <float> is probably bogus, for
instance.  But the idea is that SaveInt would save the integer
value, clparser then would match an optional decimal-point,
followed by another optional integer (which 'myactions' would
save into a different variable), and then 'SaveFloat' would
pick up the two integer pieces and create a floating-point
number to match.

Clparser was very convenient for doing this kind of thing, and
I do hope to dust it off and see about using it once again...


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04210113b557b8819553>