Standalone Scripts
For standalone scripts (appearing as .pkt files and registered in programs.cfg), such scripts must begin with a comment line giving the path to the pikt script interpreter:
#!/usr/local/pikt/bin/piktor as it might appear, with a PIKT macro, in programs.cfg:
#!=piktFollowing that, the script must have one or more Pikt statements, perhaps mixed with blank lines or comment lines.
Here is a sample Pikt script to send a SIGHUP signal to inetd as the script would appear in programs.cfg:
SigHupInetd // restart inetd path "=prgdir/SigHupInetd.pkt" mode 750 uid 0 gid 1 #!=pikt # send a SIGHUP signal to inetd init input proc # but what about args to inetd? #if solaris "=ps -e -o pid,comm | =grep inetd" #elif linux | freebsd | openbsd "=ps -xc | =grep inetd | =grep -v grep" #elif hpux | irix | aix "=ps -e | =awk '{print $1 " " $4}' | =grep inetd" #endif dat $inetdpid 1 # 'pid' is a reserved var name dat $inetdproc $ # unused rule =exec "=kill -HUP $inetdpid"After installing this on the PIKT slave systems with
# piktc -iv +P SigHupInetd +H ...you would have the SigHupInetd.pkt script in the PIKT prgdir:
#!/usr/local/pikt/bin/pikt # send a SIGHUP signal to inetd init input proc # but what about args to inetd? "/usr/bin/ps -e -o pid,comm | /usr/bin/grep inetd" dat $inetdpid 1 # 'pid' is a reserved var name dat $inetdproc $ # unused rule exec "/usr/bin/kill -HUP $inetdpid"(Note that you can edit Pikt .pkt script files directly without registering them in programs.cfg or installing them from the PIKT master.)
You can directly execute this with
# SigHupInetd.pkt [assumes that the PIKT prgdir is in your path](be sure to 'chmod +x' the script file first) or via piktc with
# piktc -x +C "=prgdir/SigHupInetd.pkt" +H ...Note several differences with Pikt alarm scripts (appearing within .alt files and registered in alarms.cfg): (a) the script name appears nowhere in the script (rather, it is in the script file name, in this case, SigHupInetd.pkt); (b) on the client, there is no special indentation (the script must still follow the usual indentation rules in the master programs.cfg); (c) you may embed #-style comments within the script (#-style comments are not supported within alarms.cfg alarm scripts); (d) the piktc preprocessor will honor your line and whitespace layout (and not rewrite the layout as it would when installing alarms.cfg alarm scripts as .alt files).
To repeat: #-style comments are reserved for standalone, directly executable Pikt scripts maintained within programs.cfg (or perhaps edited directly) and installed as .pkt files. #-style comments are illegal in alarm scripts maintained within alarms.cfg and installed in .alt files. (For alarm scripts, just use //-style and /* */ comments instead.)
For #-style comments, there might be instances where the parser interprets #foo-style numerical variables or #foo()-style numerical functions as comments, or vice-versa. In such instances, the fix is simply to add whitespace after the # or perhaps tweak the line layout. (Admittedly, the parser is not perfected yet. Try not to get too carried away with weird commenting and script layouts.) In general, it's just good practice to add whitespace after '#' for all comments.
Because Pikt scripts might reference history values in .hst files in the PIKT hstdir, and because Pikt scripts write to .log files in the PIKT logdir, it is imperative that the script interpreter be able to find the =piktdir. Unfortunately, at least several versions of Linux and AIX (and other OSes?) strip directory paths from the script interpreter (i.e., "#!/pikt/bin/pikt" becomes simply "#!pikt", and we have been unable to find a way to convey path information to the pikt script interpreter in a reliable or straightforward way. There are at least two fixes for this problem: (a) add the PIKT bindir (e.g., /usr/local/pikt/bin) to root's program PATH; (b) specify homdir in PIKT.conf (so long as your PIKT etcdir is one of the standard locations (/etc, /etc/pikt, /usr/local/etc, /usr/local/etc/pikt).
You can use command-line arguments with standalone Pikt scripts and reference their value within the script as $ARGV[]. #ARGC is the number of command-line arguments.
For example, if you do this
# foo.pkt 1 bar "this is a test"or
# pikt +S foo.pkt 1 bar "this is a test"$ARGV[0] is the script name, foo.pkt; $ARGV[1] is "1" (a text string, not the number 1); $ARGV[2] is "bar"; $ARGV[3] is "this is a test"; and #ARGC is 3 (a number, not a string). For scripts without arguments, #ARGC is zero.
Note that you cannot pass arguments to alarm scripts (in *.alt files), and $ARGV[] and #ARGC are undefined in that context.
Refer to the sample alarms.cfg for examples.
prev page | 1st page | next page |