Parse Errors

(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 configuring and using PIKT, you will sooner or later encounter the dreaded parse error, for example:

# piktc -iv +A =alerts +H rouen

processing rouen...
May  1 03:08:39 rouen piktc[16858]: [ID 1002 ERROR] (../../../src/piktc/def.l, line 280,
defparse()) /pikt/lib/configs/alerts.cfg, at or near line 786: syntax error: #elsedef

PIKT is finicky about its configuration: it must be syntactically correct. Otherwise, it would be too easy to misconfigure something and cause some disaster (e.g., accidentally rewrite or rm the system passwd file). Doubtless, it can be annoying sometimes to deal with config file parse errors, but trust us: with PIKT's immense (and root-authorized) power, you want PIKT to be sure of your intentions. You really do need this protection.

When attempting to debug parse errors, here are a few tips to remember:

"parse error (in defparse())" suggests that you have a mistaken #ifdef-#endifdef construction somewhere (e.g., you omitted an ending #endifdef).
"parse error (in tagparse())" suggests that you have a mistaken #if-#endif construction somewhere (e.g., you used #if where you should have used #elif).
"parse error (in cfgparse())" suggests that you have a garbled your Pikt script syntax (e.g., you have misspelled a keyword, or forgotten to close a quoted string, or ...).
If none of the above applies, perhaps you have, for a machine or OS, omitted a stanza identifier or stanza contents; or failed to close a #fix-#unfix; or used '#if sys1 || sys2' instead of '#if sys1 | sys2'; or ... Really, there are many ways you could go wrong, but if a parse error is reported, 99.99% of the time it's for real.
Sometimes parse errors reported in one file actually stem from errors made at or near the end of the previous file. The piktc preprocessor processes files in the following order: systems.cfg, defines.cfg, macros.cfg, alarms.cfg, alerts.cfg, programs.cfg, files.cfg, objects.cfg. So a parse error reported at the beginning of objects.cfg might actually be caused by a goof at the end of files.cfg. Or an error reported at the beginning of an #include file might actually be just before the #include directive in the calling parent file.
Make sure that the last line of every config file ends with a line feed!
Remember that when debugging parse errors, comments are your friend. Try using /* */ comments to nullify entire sections of the configuration. If your problem goes away, the fault is in the commented-out section. Be sure not to nest /* */ comments, of course!
Be on friendly terms, too, with backslashes ('\'). Sometimes they will get you out of a parsing jam. For example, '#if' at the beginning of a line in an #indent'ed and #include'd Perl or shell script will cause a parser error. Changing to '\#if' or '#\if' will fix the problem.
When a parse error involves or %foo references, try coercing the data type with, e.g., #val() or $text(%foo).
For macros defining entire Pikt scripts, if the script macro ends with a quoted string, this will cause a parse error. See macros.cfg for suggested fixes.
Consider using a config file editor, such as Emacs, with unlimited undo. If your edits create a parse error, undo your changes as far back as necessary to correct your error(s).
Consider, too, using a revision control system (such as CVS). If you break your configuration, you can restore an earlier known-to-be-good configuration from the archive.
Making daily on-disk backups of your PIKT configuration is another good idea. You can use diff or some other means to identify changes and possible sources of new syntax errors.
When all else fails and you are stuck trying to debug a convoluted configuration, throw all or much of it away and start again from scratch. Issue a 'piktc -cv +H ...' every step along the way to validate your most recent changes.

1st page