Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

error(1)							     error(1)


  error	- Analyzes and disperses compiler error	messages


  error	[-n] [-q] [-s] [-v] [-t	suffix_list] [-I ignore_file] [file]

  The error program 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.


  -I ignore_file
      Takes the	names of functions to ignore from ignore_file.	If the -I
      option is	not specified, the function names are taken from a file	named
      .errorrc in the user's home directory. If	this file does not exist, no
      error messages are nullified. Function names must	be listed one per
      line in ignore_file or in	the .errorrc file.

  -n  Does not touch any files;	all error messages are sent to the standard

  -q  Queries the user whether or not to touch the file. You must enter	y or
      n, or the	locale's equivalent of an affirmative or negative response,
      before continuing. If you	do not specify the -q option, all referenced
      files (except those referring to discarded error messages) are touched
      by default.

  -s  Prints out statistics regarding the error	categorization.

  -t suffix_list
      Does not touch files whose suffixes do not appear	suffix_list. The suf-
      fix list is dot-separated, and * wildcards may be	used. For example,
      the suffix list .c.y.foo*.h allows error to touch	files ending with .c,
      .y, .foo*	and .y.

  -v  Overlays and sets	up the visual editor vi	to edit	all files touched,
      and positions the	editor at the first error in the first touched file.
      If vi cannot be found, try ex or ed from standard	places.


  Using	the error program can replace the painful, traditional methods of
  scribbling abbreviations of errors on	paper, and permits error messages and
  source code to be viewed simultaneously without machinations of multiple
  windows in a screen editor.

  The error program looks at the error messages, either	from the specified
  file file or from the	standard input,	and performs the following opera-

    +  Attempts	to determine which language processor produced each error

    +  Determines the source file and line number to which the error message

    +  Determines if the error message is to be	ignored	or not.

    +  Inserts the (possibly slightly modified)	error message into the source
       file as a comment on the	line preceding to which	the line the error
       message refers.

    +  Sends error messages that cannot	be categorized by language processor
       or content to the standard output; does not insert these	error mes-
       sages into any file.

  The error program touches source files only after all	input has been read.

  The error program 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 using the csh syntax, the following command line
  analyzes all the error messages produced by whatever programs	make runs
  when making lint:

       make -s lint | error -q -v

  The error program knows about	the error messages produced by the following

    +  as

    +  cc

    +  ccom

    +  cpp

    +  f77

    +  ld

    +  lint

    +  make

    +  pc

    +  pi

  The error program knows a standard format for	error messages produced	by
  the language processors, so is 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.

  The error program does one of	six things with	error messages:

      Some language processors produce short errors describing which file it
      is processing.  The error	program	uses these 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.

      Error messages from lint that refer to one of the	two lint libraries,
      /usr/libdata/lint/llib-lc	and /usr/libdata/lint/llib-port	are dis-
      carded, to prevent accidentally touching these libraries.	Again, these
      error messages are consumed entirely by error.

      Error messages from lint can be nullified	if they	refer to a specific
      function,	which is known to generate diagnostics which are not
      interesting. Nullified error messages are	not inserted into the source
      file, but	are written to the standard output.  The names of lint func-
      tions to ignore are taken	from either the	file named .errorrc in the
      user's home directory, or	from 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.

  Identifies Non-File-Specific Messages
      Error messages that cannot be "intuited" are grouped together, and
      written to the standard output before any	files are touched.  These
      messages are not inserted	into any source	file.

  Identifies File-Specific Messages
      Error message that refer to a specific file, but to no specific line,
      are written to the standard output when that file	is touched.

  Identifies True Errors
      Error messages that can be "intuited" are	candidates for insertion into
      the file to which	they refer.

  Only true error messages are candidates for inserting	into the file to
  which	they refer.  Other error messages are consumed entirely	by error or
  are written to the standard output. The error	program	inserts	the error
  messages into	the source file	on the line preceding the line the language
  processor found in error. Each error message is turned into a	one-line com-
  ment for the language, and is	internally flagged with	the string ### at the
  beginning of the error, and %%% at the end of	the error. This	makes pattern
  searching for	errors easier 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 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, it is	possible to insert a comment into another comment, which can
  wreak	havoc with a future compilation. To avoid this,	programs with com-
  ments	and source on the same line should be formatted	so that	language
  statements appear before comments.

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


   1.  Opens the teletype directly to do user querying.

   2.  Source files with links make a new copy of the file with	only one link
       to it.

   3.  Changing	a language processor's format of error messages	may cause
       error to	not understand the error message.

   4.  The error program, since	it is purely mechanical, does not filter out
       subsequent errors caused	by "floodgating" initiated by one syntacti-
       cally trivial error.  Humans are	still much better at discarding	these
       related errors.

   5.  Pascal error messages belong after the lines affected (error puts them
       before).	 The alignment of the \\ marking the point of error is also
       disturbed by error.

   6.  error was designed for work on CRTs at reasonably high speed. It	is
       less pleasant on	slow speed terminals, and has never been used on
       hardcopy	terminals.


      Function names to	ignore for lint	error messages.

      User's teletype.