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.