Whitespace, continuation, and quoted strings in conf files

Russ Allbery rra at stanford.edu
Mon Jun 26 03:32:02 UTC 2000

Okay, after reading through all the comments (*thank you* -- this makes it
much easier to design something that will work well in the long term),
here's what I think makes the most sense:

Outside of quoted strings, a newline ends a parameter.  The following is a
syntax error:


(i.e. with no trailing value).  If the goal is to use the default value,
just leave out the parameter entirely.  If the goal is to set the
parameter to the empty string, use:

    parameter: ""

I think this makes more sense and is more robust; the "unset" value quite
frequently won't have any good meaning, particularly for non-string

No escape characters are allowed outside of quoted strings.  This
simplifies parsing quite a bit.  So in other words, you can't say:

    newsgroups: comp.*,rec.*,\

The second line would be a syntax error.  You have to instead say:

    newsgroups: "comp.*,rec.*,\

I think this is acceptable; it shouldn't make much real difference to

The escape characters Forrest lists should be recognized in quoted
strings, probably by using his code (thanks!).  I hadn't thought of the
example of setting a value of a header that should be continued across
multiple lines; that's a really good point.

Lines inside a quoted string can be continued by ending them with a
backslash; any whitespace after the backslash before the end of the line
is ignored (I learned from hard experience that giving significance to
trailing whitespace is just asking for trouble in hand-edited files).
Similarly, I agree that any leading whitespace on the next line should
similarly be ignored.  Whitespace *before* the line-ending backslash is
included as part of the string, so if you want to give a parameter the
value "two words" using a continuation line, this will work:

    parameter: "two \

A continuation does *not* introduce a newline into the string; to do that,
use \n.

The double quotes are optional unless the parameter value contains any
whitespace, a backslash, or a semi-colon or needs to be continued across
multiple lines.

Does all of that sound reasonable to people?  That will give us "almost C"
string handling, with the only significant difference being that leading
whitespace on the line after a continuation is discarded.

Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

More information about the inn-workers mailing list