parsing braces question

[Charles Heizer]

Hello,
I'm trying to write a tcl script to parse a BIND DNS config file and
I'm haing some trouble trying to parse the braces.

example --

zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

I would like to parse this so I can read the configuation and write it
back out to make changes. Any suggestions are welcome.

Thanks,
- Charles

[Jeff.c]

I think you can use regular expression.
what kind of trouble you have ?

[Melissa Schrumpf]

Charles Heizer wrote:

You just happen to be in luck that BIND syntax uses {}'s and "'s.

If you assume that the BIND config files are written cleanly, you can
leverage Tcl's [info complete] to determine if your braces are matched.

That is, open the file for reading, use [gets] to read it line-by-line
into a variable, and after every line:

if {[info complete $data]} {
# curlies are balanced, process entry
} else {
# keep reading file
}

Of course, this will fall flat if the config file looks like this:

zone "." IN {
type hint;
file "named.ca";
}; zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

because you will never get balanced braces at the end of a line until
the end of a file.

Then again, if you have people writing BIND config files that look like
this, you have bigger problems than trying to parse them with Tcl. At
that point, I'd just read the file contents and process them
character-by-character until you find a {, then using info complete
until you find a }.

--
MKS

[Adrian Ho]

If your changes actually require parsing the config file (as opposed to
simple search-n-replace text substitution), then you can take advantage
of the fact that BIND config syntax is very close to Tcl's and [source]
the config file instead. You'd have to implement acl/options/zone/etc.
as Tcl procs, of course. Running the [source] in a safe interp
<http://wiki.tcl.tk/1496> may be a good thing, depending on your
deployment usage scenario.

A few things to watch out for:

* Avoid /* C-style comments */ in the config file. The #-style comment
is handled natively by Tcl, and the // C++-style comment is easily
handled with:

proc // {args} {}

although each comment must itself be in proper Tcl syntax (eg. no
unbalanced braces or semicolons).

* Semicolons and quotes in the original file will be "lost" in the [source],
so you'll have to insert them in the correct places upon output.

* BIND config directives ($ORIGIN, $INCLUDE, etc.) are handled by
defining the appropriate variables and procedures, and leveraging on
Tcl's own substitution mechanism. For example:

set ORIGIN BIND_origin
proc BIND_origin {domain args} {
...
}

- Adrian

[Charles Heizer]

Thanks to all who replied, after looking at the issue I decided I've
spent way to much time trying to parse others work when that might not
be the best.

So, I've decided to rewrite the conf file based on xml files which can
easliy be parsed and used to generate the conf files.

thanks for everyones input, I really apreicate it.

- Charles

[Eckhard Lehmann]

Charles Heizer wrote:

> So, I've decided to rewrite the conf file based on xml files which can
> easliy be parsed and used to generate the conf files.

Wait a moment...
Since the syntax is almost as Tcl syntax - as others pointed out
already - you can maybe use the Tclparser extension
(http://wiki.tcl.tk/1660) to parse the files. Among the ability to
parse complete Tcl stylish statements it gives you errors on unbalanced
braces and brackets, which can be catched.

Eckhard

[Adrian Ho]

On 2006-03-06, Charles Heizer <hei...@llnl.gov> wrote:

> Thanks to all who replied, after looking at the issue I decided I've
> spent way to much time trying to parse others work when that might not
> be the best.
>
> So, I've decided to rewrite the conf file based on xml files which can
> easliy be parsed and used to generate the conf files.

I'm not sure I read you right, but if you're saying your input will now
be user-generated XML in a schema you define (rather than original BIND
conf files), I'm not sure that's a good move. IMO, XML is a decent format
for data interchange and storage, but really terrible for human beings
to work with, esp. without the right tools (editor, validator, parser, etc.).

If you're asking users to give you data in some format other than BIND
config, you might as well make it Tcl syntax (though some might argue
it's close enough to cause confusion and errors), or at least something
else that is easy for your users to work with.

- Adrian

[Melissa Schrumpf]

Charles Heizer wrote:

> Thanks to all who replied, after looking at the issue I decided I've
> spent way to much time trying to parse others work when that might not
> be the best.

> So, I've decided to rewrite the conf file based on xml files which can
> easliy be parsed and used to generate the conf files.

Not that I'm criticizing your decision, but what did anyone say that
lead you to believe that parsing XML will be easier than parsing BIND?
Everything I've read leads me to believe quite the opposite.

If you think you're going to eliminate having to check error-prone
user-generated config files by using XML instead of BIND, I believe
you're mistaken. It's just as easy to miss a closing ">" as it is to
miss a closing "}."

And actually, I would like to offer one small criticism of your choice:
if you're going to force the use of non-standard configuration files,
then you're going to spend a lot of extra time writing documentation of
the new file format, and everyone who uses it is going to spend a lot of
extra time learning the format. If you stick with a format that is
already well-established, it's likely that you'll cause your users a lot
less grief, and will be building a maintainable system, as opposed to
one with a lot of cruft that will simply be replaced the next time a
major update is needed. I say stick with a format like BIND -- XML is
not a format in the same sense, it is an encapsulation method; it
doesn't define anything.

--
MKS