inncheck improvements

Julien ÉLIE julien at
Wed Jul 6 19:28:23 UTC 2011

Hi Florian,

> Be more restrictive than current parsers and config-syntax / lib/confparse.c
> combined, so that anything that passes inncheck will be ok both now and in
> the future.

I think it is a nice move for the time being.  At least until we have 
real parsers that do the complete check for us.  Like inn.conf:

     system ("$INN::Config::innconfval", '-C');

I bet your new useful additions to inncheck will live for a few years. 
So that's a great investment.  Thanks a lot.

> - comments:
>        config-syntax says "comments at the end of lines aren't permitted",
>        but this seems to be standard practice...

Oh, yes, I never noticed it.
We indeed have an error in inn.conf if a hash sign (#) appears at the 
end of a line for a comment:

innconfval: /home/news/etc/inn.conf:32: parse error: saw string, 
expecting semicolon or newline

>       Weird things can happen if a "#" is encountered inside a string
>       =>  forbid # in strings?

If weird things happen, we should report a warning in inncheck.

> - multiple variables:
>        config-syntax says multiple variable settings can be on one line when
>        separated by semicolon; incoming.conf parser knows nothing about this
>        =>  enforce one variable per line?

Currently, yes, we should report a warning in inncheck.

> - double assignments:
>        in practice, the latter takes precedence, says config-syntax,
>        though I wouldn't bet on it for current incoming.conf...

Isn't it already checked in your patch?

         print "$file:$line: duplicate option $word in $group->{'type'} 
             if exists $group->{$word} and not defined 


/home/news/etc/incoming.conf:28: duplicate option password in peer 

Julien ÉLIE

« Le cercle est le plus long chemin d'un point au même point. »
   (Tom Stoppard, _Every Good Boy Deserves Favour_)

More information about the inn-workers mailing list