Known Problems and Limitations
(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.)
In Pikt scripts, generally every item serves a semantic purpose. So, for example, there are no semicolons to indicate the end-of-line, nor are parentheses surrounding logical test required (they are optional). This convenience comes at a price. In certain rare circumstances, your script may not parse. Here is one such circumstance:
for #i=-1 -#i<=10 #i-=1This will break the parser, because the "-1 -#i" runs together. The fix here is simple: Just reverse the exit condition:
for #i=-1 10>=-#i #i-=1For standalone Pikt scripts, the parser might interpret #foo-style numerical variables or #foo()-style numerical functions as comments, or vice-versa.
These parse errors are quite infrequent, and are usually easily fixable. (For example, always use whitespace after the # comment character.)
Except in some arithmetical or complex logical expressions, parentheses are unnecessary. You're sometimes better off avoiding them.
(We continue to revise and perfect the parsers. Hopefully, someday, absolutely all ambiguous code will parse.)
In scripts, you are limited to 255 different variable names. (That is, within an alert, each alarm script has its own separate 255-member variable name set.) This might seem at first to be a severe limitation, but it's not really. Very few situations would require anywhere near that many, let alone more than 255. In those situations, just use Perl, Python or whatever other language you prefer, or resort to arrays.
For numerically indexed arrays, indices are limited to 2147483647. This should be way more than enough for the problem domain (systems administration) for which Pikt is intended.
For numerically indexed arrays, you are restricted to from one to three dimensions. Here, too, this should more than suffice for most situations. (Code is in place, but not activated, to take Pikt to a higher number of array dimensions, if ever this is needed.)
So, it is actually possible to store as many as 255 X 2147483647 X 2147483647 X 2147483647 values within a Pikt script. (More than that, if you include $0, $1, $2, ..., and the built-in variables like $inlin. Of course, you would probably run out of system memory before reaching these limits.) If ever any of these limitations becomes an issue, just use Perl, Python, or whatever other language you like.
Input strings are limited to 512 characters. This should be more than enough for most situations. If not, again use some other language. Internally, strings are effectively unlimited in length.
User-defined functions are not currently supported. (Their inclusion is planned for a future release. They will probably appear in a new, ninth config file, functions.cfg.) For now, if you really need a custom function (and don't want to recode pikt itself), you can fake it by $command()'ing or #system()'ing Pikt scripts or scripts written in other languages, passing arguments in the script command string. In many situations, PIKT macros-with-arguments substitute for formal user-defined functions quite nicely (see the sample macros.cfg).
Compared to other high-powered scripting languages such as Awk and Perl, Pikt scripts don't run particularly fast. Regexp pattern matching is especially slow. When practical, employ awk, egrep, sed, and other Unix filters to prune your Pikt script input (either by piping to a filter in your 'input proc' statement, or by adding a separate 'filter' statement; see Init Section), then use Pikt regexps in your rule statements to inspect the remaining input lines. In certain high-data-volume situations (for example, when scanning huge log files), you might be better off invoking Awk or Perl or some other optimized data scanning utility to handle your pattern matching exclusively.
In future versions, we might relax some of these limitations. The Pikt script language is not an all-purpose programming language. Pikt was designed to aid in systems administration, and to have scripts run quickly and in a small memory space. As of now, we are not convinced that extending Pikt's reach is worth the added processing and memory overhead that would entail. In the course of its development, much time and effort was spent on adding features to the Pikt script language that are, after all is said and done, little used. We are guided by practicality and usefulness in further development, not by attainment of some lofty conceptual ideal.
prev page | 1st page | next page |