Alfred Morgan(alf...@54.org) on 2019.03.12 01:24:40 -0500:
> httpd uses the configuration processor that relayd uses so I was curious to
> see how this block of sub options were explained in relayd.conf(5) and
Good idea.
But dont draw general conclusions from this please. The parsers are similar
because they were (in part) written by the same author. no wonder they share
syntactic feature.
Every time we write one of these parsers, its a mix of "how do we apply our
general syntax to this new domain?", "what do i re-use to make it easier for
people?", "how lazy am i?" and "%^$#@#$ yacc is crazy!!!".
/B.
> interestingly enough this is not explained there either but there are
> examples of the multiple option block being used. One thing I learned from
> relayd.conf examples was that the sub options can also be separated by a
> coma allowing multiple sub options to be written on one line inside the
> brackets. I confirmed this works the same in httpd.conf. This gives us
> these possibilities to write sub options:
> A)
> connection max requests 10
> connection timeout 600
>
> B)
> connection {
> max requests 10
> timeout 600
> }
>
> C)
> connection { max requests 10, timeout 60 }
>
> While reading the man page for relayd.conf I found this easy to read and
> simple explanation that we may draw inspiration from -- although this still
> does not explain the sub option block:
> """
> It is possible to specify multiple listen directives with different IP
> protocols in a single redirection configuration:
> redirect "dns" {
> listen on dns.example.com tcp port 53
> listen on dns.example.com udp port 53
>
> forward to <dnshosts> port 53 check tcp
> }
> """
> I think we are struggling on how to be clear because option and sub-option
> are named the same and the need to distinguish between other
> "non-sub-options", if that makes any sense.
> We could go the relayd.conf(5) method and don't mention anything about
> sub-option blocks and just give examples such as A, B, and C above.
>
> On Mon, Mar 11, 2019 at 5:21 PM Evan Silberman <e...@jklol.net> wrote:
>
> > Jason McIntyre <j...@kerhand.co.uk> wrote:
> > > On Mon, Mar 11, 2019 at 12:29:41PM -0700, Evan Silberman wrote:
> > > > Jason McIntyre <j...@kerhand.co.uk> wrote:
> > > > >
> > > > > Index: httpd.conf.5
> > > > > ===================================================================
> > > > > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> > > > > retrieving revision 1.103
> > > > > diff -u -r1.103 httpd.conf.5
> > > > > --- httpd.conf.5 19 Feb 2019 11:37:26 -0000 1.103
> > > > > +++ httpd.conf.5 11 Mar 2019 19:05:57 -0000
> > > > > @@ -155,7 +155,10 @@
> > > > > .Xr patterns 7 .
> > > > > .El
> > > > > .Pp
> > > > > -Followed by a block of options that is enclosed in curly brackets:
> > > > > +It is followed by a block of directives and values, enclosed in
> > curly brackets.
> > > > > +Directives which take multiple
> > > > > +.Ar option
> > > > > +values may also group these options in curly brackets.
> > > >
> > > > This is better than mine but I don't think the "also" has a referent
> > here. Maybe:
> > > > "Directives which take multiple option values may be repeated or may
> > group the
> > > > options in curly brackets." This excludes the possible interpretation
> > that e.g.
> > > > 'log access "acces_log" error "error_log"' is valid syntax.
> > > >
> > >
> > > "also" because we just said that directives and values are enclosed in
> > > curly brackets. so "also" meaning "in the same way as we just showed
> > > you".
> >
> > You're right, reading the context more carefully this makes perfect sense.
> > >
> > > "repeated" is confusing i think (like you would specify the same option
> > > value twice).
> >
> > Fair enough. I have no further quibbles.
> >
> > Evan Silberman
> >
> --
> -alfred
>
--
