ERROR(1) BSD ERROR(1)
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. It can replace the painful,
traditional methods of scribbling abbreviations of errors on paper, and
permits you to view error messages and source code simultaneously without
machinations of multiple windows in a screen editor.
error looks at the error messages, either from the specified file name or
from the standard input, and attempts to determine which language
processor produced each error message. It determines the source file and
line number to which the error message refers, determines if the error
message is to be ignored or not, and inserts the (possibly slightly
modified) error message into the source file as a comment on the line
preceding the line to which the message refers.
error does not insert error messages that can't be categorized by
language processor or content into any file; instead, it sends them to
the standard output. error touches source files only after all input has
been read. If you specify the -q query option, error asks you to
confirm any potentially dangerous (such as touching a file) or verbose
action. Otherwise error proceeds on its merry business. If you specify
the -t touch option and associated suffix list, error touches only those
files with suffixes in the suffix list. You can also specify -v) to ask
error to invoke vi(1) on the files in which error messages were inserted;
this means you don't have 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 put error messages
on their standard error file; others put their messages on the standard
output. Hence, both error sources should be piped together into error.
For example, when you use the csh(1) syntax,
make -s lint |& error -q -v,
error analyzes all the error messages produced by whatever programs make
runs when making lint.
error knows about the error messages produced by: make, cc, cpp, ld,
lint, and f77. error knows a standard format for error messages produced
by the language processors, so it is sensitive to changes in these
formats. Some error messages refer to more than one line in more than
one file; error duplicates the error message and inserts it at all the
places referenced.
error does one of the following six things with error messages.
Synchronize
Some language processors produce short errors describing which
files they are processing. error uses these to determine the
filename for languages that don't include the filename in each
error message. error consumes these synchronization messages
entirely.
Discard error discards messages from lint that refer to one of the two
lint libraries, /usr/lib/llib-lc and /usr/lib/llib-port, to
prevent accidentally touching these libraries. Again, error
consumes these messages entirely. error.
Nullify error can nullify messages from lint if they refer to a
specific function, that is known to generate uninteresting
diagnostics. error does not insert nullified error messages
into the source file, but writes them to the standard output.
It takes the names of functions to ignore from either the file
named .errorrc in your home directory, or the file named by the
-I option. If the file does not exist, error does not nullify
any error messages. If the file does exist, there must be one
function name per line.
Not file specific
error groups together messages that can't be intuited and
writes them to the standard output before it touches any files.
It does not insert them into any source file.
File specific
error writes messages that refer to a specific file, but to no
specific line, to the standard output when it touches that
file.
True errors
Error messages that can be intuited are candidates for
insertion into the file they refer to.
Only true error messages are candidates for inserting into the file they
refer to. error consumes other error messages entirely or writes them to
the standard output. error inserts the error messages into the source
file on the line preceding the line the language processor found in
error. It turns each error message into a one line comment for the
language, and flags it internally with the string "###" at the beginning
of the error, and "%%%" at the end of the error. This makes pattern
searching for errors with an editor easier, and allows you to remove the
messages easily. In addition, each error message contains the source-
line number for the line the message refers to. You can recompile a
reasonably formatted source program with the error messages still in it,
without having the error messages themselves cause future errors. For
poorly formatted source programs in free-format languages, such as C or
Pascal, you can insert a comment into another comment, which can wreak
havoc on a future compilation. To avoid this, you should put language
statements before comments in programs that have comments and source on
the same line.
OPTIONS
-n Do not touch any files; send all error messages to the standard
output.
-q Specifies that error queries you before it touches the file.
You must answer y or n if you want error to continue. If you
do not specify -q, you give error consent to touch all
referenced files (except those referring to discarded error
messages).
-v After all files have been touched, overlay the visual editor
vi, set up to edit all files touched, and positioned in the
first touched file at the first error. If vi can't be found,
try ex or ed from standard places.
-t Take the following argument as a suffix list. error does not
touch files whose suffixes do not appear in the suffix list.
The suffix list is dot separated, and asterisk (*) wildcards
work. Thus the suffix list
".c.y.foo*.h"
allows error to touch files ending with .c, .y, .foo* and .y.
-s Print statistics regarding the error categorization. This
option is not too useful.
error catches interrupt and terminate signals, and if in the insertion
phase, terminate what it is doing in an orderly fashion.
BUGS
Opens /dev/tty directly to do user querying.
Source files with links make a new copy of the file with only one link to
it.
Changing a language processor's format of error messages may prevent
error from understanding the error message.
Because error is purely mechanical, it does not filter out subsequent
errors caused by `floodgating' initiated by one syntactically trivial
error. Humans are still much better at discarding these related errors.
error was designed for work on CRT's at reasonably high speed. It is
less pleasant on slow-speed terminals, and has never been used on
hardcopy terminals.
FILES
~/.errorrc Function names to ignore for lint error messages
/dev/tty User's teletype