18.5 The Behavior of a Rule
Each individual rule (R command) in the
configuration file can be thought of as a while-do statement. Recall
that rules are composed of an LHS (lefthand side) and an RHS
(righthand side), separated from each other by tabs. As long as
(while) the LHS matches the workspace, the workspace is rewritten
(do) by the RHS (see Figure 18-2).
Consider a rule in which we want the name tom in
the workspace changed into the name fred. One
possible rule to do this might look like this:
R tom fred
If the workspace contains the name tom, the LHS of
this rule matches exactly. As a consequence, the RHS is given the
opportunity to rewrite the workspace. It does so by placing the name
fred into that workspace. The new workspace is
once again compared to the tom in the LHS, but now
there is no match because the workspace contains
fred. When the workspace and the LHS do not match,
the rule is skipped, and the current contents of
the workspace are carried down to the next rule. Thus, in our
example, the name fred in the workspace is carried
down.
Clearly, there is little reason to worry about endless loops in a
rule when using names such as tom and
fred. But the LHS and RHS can contain
pattern-matching and replacement operators, and those operators
can lead to loops. To illustrate, consider the
following example of a test.cf file:
V10
Stest
R fred fred
Clearly, the LHS will always match fred both
before and after each rewrite. Here's what happens
when you run the -bt rule-testing mode on this
file:
% /usr/sbin/sendmail -bt -Ctest.cf
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> test fred
test input: fred
Infinite loop in ruleset test, rule 1
test returns: fred
>
V8 sendmail discovers the loop and breaks it for
you. Earlier versions of sendmail would hang
forever.
Note that you can avoid the chance of accidental loops by using
special prefix operators on the RHS, as described in Section 18.7.2 and Section 18.7.3.
|