error man page on DigitalUNIX

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
DigitalUNIX logo
[printable version]

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  proces‐
       sors to the source file and line where the errors occurred.

       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
       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 file.  Does not touch any files; all error mes‐
       sages are sent to the standard output.  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.  Prints  out  statis‐
       tics  regarding	the  error categorization.  Does not touch files whose
       suffixes do not appear suffix_list. The suffix list  is	dot-separated,
       and  * wildcards may be used. For example, the suffix list allows error
       to touch files ending with and 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	speci‐
       fied  file  file or from the standard input, and performs the following
       operations: Attempts to determine  which	 language  processor  produced
       each  error  message.   Determines  the	source file and line number to
       which the error message refers.	Determines if the error message is  to
       be ignored or not.  Inserts the (possibly slightly modified) error mes‐
       sage 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 messages into any file.

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

       The error program is intended to be run with its	 standard  input  con‐
       nected  via  a pipe to the error message source.	 Some language proces‐
       sors 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

       The  error  program knows about the error messages produced by the fol‐
       lowing programs: 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 for‐
       mats. 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 lan‐
       guage processors produce short errors describing which file it is  pro‐
       cessing.	  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 functions to ignore are
       taken from either the file named 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 func‐
       tion  name  per	line.	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.
       Error message that refer to a specific file, but to no  specific	 line,
       are  written  to	 the standard output when that file is touched.	 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 comment 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  mes‐
       sage  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 com‐
       pilation. To avoid this, programs with comments and source on the  same
       line should be formatted so that language statements appear before com‐

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

       Opens  the  teletype  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 cause error to not
       understand the error message.  The error program, since	it  is	purely
       mechanical,  does not filter out subsequent errors caused by “floodgat‐
       ing” initiated by one syntactically trivial error.   Humans  are	 still
       much  better at discarding these related errors.	 Pascal error messages
       belong after the lines affected (error puts them before).   The	align‐
       ment  of	 the \\ marking the point of error is also disturbed by error.
       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 hard‐
       copy terminals.

       Function names to ignore for lint error messages.  User's teletype.


List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net