INN config file parsing infrastructure

Russ Allbery rra at
Thu May 4 23:44:56 UTC 2000

Todd Olson <tco2 at> writes:

> What about parameters with no values (such as innflags: in inn.conf) ??

I think that should be a syntax error.  If you really want the empty
string as the setting for a parameter, that should be explicitly written

    parameter: ""

> Hum ... I'm having trouble deducing how you will handle the case
> where I want to write 
>      parameter:  first_token \
>           second_token

> and have it mean
>      parameter:  first_token second_token

The intention is for backslashes to escape newlines *only* within quoted
strings.  Regardless, though, the above is a syntax error, as it assigns
the value "first_token" to parameter and then the parser is going to be
looking for a new parameter.  Any value containing whitespace *must* be

I don't see any reason to worry about continuation lines outside of quoted
strings, since the goal is to make the rest of the syntax insensitive to

    group blah { parameter: value; parameter2: value2 }

should be equivalent to:

    { parameter:
    parameter2: value2

or whatever other weird thing you want.  The only reason to require a
newline or a semicolon to separate parameters is to be able to catch the
common syntax error of a value with embedded whitespace that isn't

> and if there is not a first non-whitespace?

Syntax error.  Actually, if you write:


you'll actually set parameter1 to the value "parameter2:", so inncheck
should check for this.  (Or we could require that the value start on the
same line as the parameter, but I'm not sure that's necessary.)

> The group idea is very useful ...  But it could become hard to figure
> out by hand from the config file what value is set for what.

Why?  I'm not following why this would be.

> It seems essential to the infrastructure to have a tool (based on the
> parse library) that allows you to ask
>     1) for this "group" what are all the parameter:value pairs
>        set explicitly or implicitly
>     2) which of these are set only be defaults built into inn

This information is all available and part of the structs in my original
proposal.  1) in fact will be static const data generated from the .def

> Hum ... #2 raises the question of defaults built into code.

That's the reason to have initialization and validation functions for
groups.  Those functions handle the programmatic defaults for those
groups.  Each separate config file has separate issues to handle there
(inn.conf has quite a few of these).

> And in the case of something like readers.conf it a tool that let you on
> the command line enter a particular address & and userid and show how
> they were rejected or accepted by the different stanzas would be a
> useful debugging tool.

That's separate from the configuration file parser.  The reader
authentication code in nnrpd has that information, not the configuration
file parser; the config file parser knows nothing about semantics, only
syntax.  It just generates a list of groups containing parameters with
known types; it has no idea how that information will be used or what it's
related to.

> While I'm at it a similar sort of tool for testing particular newsgroup
> names against wildmats (eg in incoming.conf) would be useful for testing
> and developing wildmats.

Reworking wildmat some is on my list, but I'm trying not to start too many
things at once.  :)

Russ Allbery (rra at             <>

More information about the inn-workers mailing list