.so ../defs.man.in \"@@@PRE@@@
.
.\"--------------------------------------------------------------------------
-.TH peers.in 5 "27 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
+.TH peers.in 5tripe "27 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
.
.\"--------------------------------------------------------------------------
.SH "NAME"
for sections. If a section contains an assignment
.IP
.BI "@inherit = " parent
+.RB [[,]
+.I parent
+\&...]
.PP
then any lookups which can't be satisfied in that section will be
-satisfied instead from the
+satisfied instead from its
.I parent
-section (and, if necessary, its parent in turn, and so on). Note that
+sections (and, if necessary, their parents in turn, and so on).
+.PP
+.hP \*o
+If a value can be found for a key via multiple parents then all of them
+must report the
+.I same
+value. This restriction may be relaxed somewhat, if it turns out that a
+more flexible notion of multiple inheritance is useful.
+.hP \*o
+It's not allowed for a section to inherit, possibly indirectly, from
+itself. Currently errors of this kind are only diagnosed when a cycle
+is encountered while looking up a key and none of the sections on the
+path from the original section up to and round the cycle define a value
+for it. Future versions of this program might be more picky.
+.PP
+Note that
.BI $( key )
substitutions in the resulting value will be satisfied from the original
-section (though falling back to scanning the parent section). For
+section (though falling back to scanning parent sections). For
example, given the sections
.VS
[parent]
-detail = in parent
+detail = in $(name)
blurb = expand $(detail)
+
+[child]
+@inherit = parent
.VE
+the key
+.B blurb
+takes the value
+.RB ` "expand in parent" '
+in section
+.BR parent ,
+and
+.RB ` "expand in child" '
+in section
+.BR child .
+.PP
Apart from its effect on lookups, as just described, the
.B @inherit
key is entirely ignored. In particular, it is never written to the