NAME

error − analyze and disperse compiler error messages

SYNOPSIS

error [ −n ] [ −s ] [ −q ] [ −v ] [ −t suffixlist ] [ −I ignorefile ] [ name ]

DESCRIPTION

Error analyzes and optionally disperses the diagnostic error messages produced by a number of compilers and language processors to the source file and line where the errors occurred.  Error replaces the complex, standard methods of recording abbreviations of errors in writing, and permits error messages and source code to be viewed simultaneously without machinations of multiple windows in a screen editor. 

Error views the error messages, either from the specified file name or the standard input, and attempts to determine which language processor produced each error message.  Error then determines the source file and line number to which the error message refers, determines whether or not the error message is to be ignored, and inserts the (possibly slightly modified) error message into the source file as a comment on the preceding line to which the line the error message refers.  Error messages which cannot be categorized by language processor or content are not inserted into any file, but are sent to the standard output.  Error messages are displayed only after all input has been read.  By specifying the −q query option, the user is asked to confirm any potentially dangerous (e.g., touching a file) or verbose action.  Otherwise, error proceeds as usual.  If the −t touch option and associated suffix list is given, error restricts itself to only alter those files with suffices in the suffix list.  Error also can be requested (by specifying −v) to invoke vi(1) on the files in which error messages were inserted; this obviates the need to remember the names of the files with errors.

Error is intended to be run with its standard input connected via a pipe to the error message source.  Some language processors place error messages on their standard error file; other processors place their messages on the standard output.  Therefore, both error sources should be piped together into error.  For example, when using the csh syntax, the following

make −s lint |& error −q −v

analyzes all the error messages produced by whatever programs make runs when making lint. 

Error recognizes the error messages produced by: make, cc, cpp, ccom, as, ld, lint, pi, pc and f77.  Error also recognizes standard format for error messages produced by the language processors, and is therefore sensitive to changes in these formats.  For all languages, except Pascal, error messages are restricted to be on one line.  Some error messages refer to more than one line in more than one file; error duplicates the error message and inserts it at all of the places referenced points. 

Error performs one of the following six functions with error messages. 

synchronize
Some language processors produce short errors describing which file it is processing. Error uses these errors to determine the file name for languages that do not include the file name in each error message.  These synchronization messages are consumed entirely by error. 

discard Error messages from lint that refer to one of the two lint libraries, /usr/lib/llib-lc and /usr/lib/llib-port are discarded to prevent accidently altering these libraries.  These error messages also are consumed entirely by error. 

nullify Error messages from lint can be nullified if they refer to a specific function which is known to generate diagnostics which are not of specific interest.  Nullified error messages are not inserted into the source file, but are written to the standard output.  The names of functions to ignore are taken from either the file named .errorrc in the user’s home directory, or the file named by the −I option.  If the file does not exist, no error messages are nullified.  If the file does exist, there must be one function name per line. 

not file specific
Error messages that cannot be intuited are grouped together, and written to the standard output before any files are altered. These errors are not inserted into any source file.

file specific Error message that refer to a specific file, but to no specific line, are written to the standard output when that file is altered. 

true errors Error messages that can be intuited qualify for insertion into the file to which they refer. 

Only true error messages qualify for inserting into the file to which they refer.  Other error messages are consumed entirely by error or are written to the standard output.  Error inserts the error messages into the source file on the line preceeding the line the language processor found in error.  Each error message is changed into a one line comment for the language.  The message is then internally flagged with the string “###” at the beginning of the error, and “%%%” at the end of the error.  This flagging pattern simplifies searching for errors with an editor, and allows the messages to be easily removed.  In addition, each error message contains the source line number for the line to which the message refers.  A reasonably formatted source program can be recompiled with the error messages still contained, without the error messages themselves causing additional errors.  For poorly formatted source programs in free format languages, such as C or Pascal, it is possible to insert a comment into another comment, which can greatly complicate a future compilation; to avoid this, format the source program so no language statements are on the same line as the end of a comment. 

Options available with error are as follows:

−n Do not touch any files; all error messages are sent to the standard output. 

−q The user is queried whether she/he wants to alter the file.  A yes (“y”) or no (“n”) response to the question is necessary to continue.  Absence of the −q option implies that all referenced files (except those refering to discarded error messages) are to be altered. 

−v After all files have been altered, overlay the visual editor vi, with it set up to edit all altered files, and positioned in the first altered file at the first error.  If vi cannot be located, try ex or ed from standard places. 

−t Take the following argument as a suffix list.  Files whose suffices do not appear in the suffix list are not altered.  The suffix list is dot separated, and “\(**” wildcards functions; Therefore, the following suffix list:

     ".c.y.foo\(**.h"

allows error to alter files ending with “.c”, “.y”, “.foo\(**” and “.y”. 

−s Print out statistics regarding the error categorization.  This printout is of limited use, as it does provide specifically outline errors. 

Error catches interrupt and terminate signals, and if in the insertion phase, will orderly terminate what it is doing. 

AUTHOR

Robert Henry

FILES

~/.errorrcfunction names to ignore for lint error messages
/dev/ttyuser’s teletype

BUGS

Opens the teletype directly to perform user querying. 

Source files with links produce a new copy of the file with only one link. 

Changing a language processor’s format of error messages may cause error to not comprehend the error message. 

Since it is purely mechanical, error does not filter out subsequent errors caused by ‘floodgating’, which is initiated by one syntactically trivial error.  It is recommended that users themselves discard these related errors. 

Pascal error messages belong after the lines affected (error places messages before these lines).  The alignment of the ‘|’ marking the point of error is also disturbed by error. 

Error was designed for operating on CRT’s at reasonably high speed.  It is less expedient on slow speed terminals, and has never been used on hardcopy terminals. 

4th Berkeley Distribution  —  %W% %Q% %Y%