Begin, End & Rule Sections

(NOTE: Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

Next come action statements, grouped in begin, end, and rule sections.

For example, here is a script (in the form of a macro, for broad generality) to report crontab changes:

crontab_change(u)

        init
                status =piktstatus
                level =piktlevel
                task "Report changes in (u) crontabs"
                input proc "if [ -e =hstdir/log/(u).crontab.bak ];
                            then =diff =hstdir/log/(u).crontab.bak =hstdir/log/(u).crontab
                            else =cat =hstdir/log/(u).crontab 2>/dev/null; fi"

        begin
                doexec wait "=crontab -u (u) -l > =hstdir/log/(u).crontab"

        rule
                output mail $inlin

        end
                doexec wait "=mv =hstdir/log/(u).crontab =hstdir/log/(u).crontab.bak"

Before input processing, you might have a begin section, for example to initialize some variables or to take some other preliminary actions. (In the example script, the begin section saves 'crontab -l' output to disk.)

The heart of a Pikt script is the main processing loop: A line of input (from a proc, file, or logfile) is read in, then acted upon, the next line is read in and acted upon, and so on until all input is exhausted. (In the example script, in the 'input proc' statement, the current crontab disk file is diff'ed against a saved backup. In the single rule statement (in other scripts, there may be and usually are more than one), the diff output (if any) is e-mailed to the designated (in alerts.cfg) alert recipients.)

After input processing, you might add an end section, for actions taken at the conclusion of input processing. (In the example script, the current crontab save file is mv'ed to its backup version, for diff'ing against the current version the next time around.)

In other words:

        begin                                    [optional]
               
               
                ...

[while there's another input line]               [optional]

        rule
               
               
                ...

        rule
               
               
                ...

        ...

[endwhile]

        end                                      [optional]
               
               
                ...

(As you might see, this is all very Awk-like.)

Note that begin, rule, and end sections are individually optional, but the script must have at least one. That is, you might have a script with only a begin section, or only an end section, or only one or more rule sections, or some combination of the three. Another requirement is that begin must precede rules, and end must follow begin and rules. Here are the possibilities:

        begin

        end

        begin
        end

        rules

        begin
        rules

        rules
        end

        begin
        rules
        end

It used to be the case that PIKT would open script input in the init section, and subsequently move on to the begin (and rules and end) section(s). Now, alarm input is opened just after the begin section and right before any rule statements.

In other words, and despite appearances, the actual processing sequence of a Pikt script is:

Do the begin section (if any).
Open script input (in the init section's 'input ...' statement).
Do the rules processing on that input.
Close script input (done automatically; there is no need for you to do this explicitly).
Do the end section (if any).

A Pikt script input processing loop comprises one or more rule sections. Strictly speaking, there is never a need to break up the set of input processing statements into separate rule sections, but doing so helps clarify program logic. (A rule line is also a handy place to put comments.)

For example, in a passwd file checking script with this 'input proc' statement

                input file "/etc/passwd"

passwd entries are fed to the rules sections, one passwd line after another. Here are just some of the rules you might apply to each input passwd line:

        ...

        rule    // non-root uid 0's
                if    $uid eq "0"
                   && (    $user !~ "^(root|sundiag|sysdiag|smtp)$"
                        || (    $user =~ "^(sundiag|sysdiag)$"
                             && $password ne "*"
                           )
                      )
                        output mail "User $user has UID OF 0!"
                        output syslog "User $user has UID OF 0!"
                endif

        rule    // no password
                if $password eq ""
                        output mail "User $user has NO PASSWORD!"
                        output syslog "User $user has NO PASSWORD!"
                endif

        rule    // no uid
                if $uid eq ""
                        output mail "User $user has no uid!"
                        output mail "  $inline"
                endif

        rule    // no gid
                if $gid eq ""
                        output mail "User $user has no gid!"
                        output mail "  $inline"
                endif

        ...

Although it would be possible to combine all of the rules checks into a single, all-encompassing rule section, doing so would obscure the processing logic.

There are additional benefits to using multiple rules sections. See Pikt Rule Sections for details.

Note that, in addition to the implicit, built-in data processing loop (the 'input proc' and rules tandem), you can also achieve additional data processing loops within a Pikt script using a combination of #fopen()/#popen(), #read(), and #fclose()/#pclose().

Refer to the sample alarms.cfg for many more examples.

1st page