Unix/Linux Go Back    


BSD 2.11 - man page for error (bsd section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


ERROR(1)										 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 error messages and source code to  be  viewed  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 stan-
       dard input, and attempts to determine which language processor produced	each  error  mes-
       sage, determines the source file and line number to which the error message refers, deter-
       mines 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 to which
       the line the error message refers.  Error messages which can't be categorized by  language
       processor  or content are not inserted into any file, but are sent to the standard output.
       Error touches source files only after all input has been read.  By specifying the -q query
       option,	the  user is asked to confirm any potentially dangerous (such as touching a file)
       or verbose action.  Otherwise error proceeds on its  merry  business.   If  the	-t  touch
       option and associated suffix list is given, error will restrict itself to touch only those
       files with suffices in the suffix list.	Error also can be asked  (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 mes-
       sage  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,

	      make -s lint |& error -q -v

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

       Error knows about the error messages produced by: make, cc, cpp, ccom, as, ld,  lint,  pi,
       pc,  f77, and DEC Western Research Modula-2.  Error knows a standard format for error mes-
       sages 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 files;  error  will	duplicate
       the error message and insert it at all of the places referenced.

       Error will do one of six things with error messages.

       synchronize
		 Some  language  processors produce short errors describing which file it is pro-
		 cessing.  Error uses these to determine the file name for languages  that  don't
		 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/share/lint/llib-lc  and /usr/share/lint/llib-port are discarded, to prevent
		 accidently touching these libraries.  Again, these error messages  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  interesting.	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 users'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.

       not file specific
		 Error	messages  that can't be intuited are grouped together, and written to the
		 standard output before any files are touched.	They will not  be  inserted  into
		 any source file.

       file specific
		 Error	message that refer to a specific file, but to no specific line, are writ-
		 ten to the standard output when that file is touched.

       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 they refer to.  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 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 the message refers to.  A  rea-
       sonably	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 comments and source on the same line should be formatted so that lan-
       guage statements appear before comments.

       Options available with error are:

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

       -q   The user is queried whether s/he wants to touch the file.  A ``y'' or  ``n''  to  the
	    question  is necessary to continue.  Absence of the -q option implies that all refer-
	    enced files (except those referring to discarded error messages) are to be touched.

       -v   After all files have been touched, overlay the visual editor vi with  it  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.  Files whose suffixes do not appear  in
	    the  suffix  list are not touched.	The suffix list is dot separated, and ``*'' wild-
	    cards work.  Thus the suffix list:

		 ".c.y.foo*.h"

	    allows error to touch files ending with ``.c'', ``.y'', ``.foo*'' and ``.y''.

       -s   Print out statistics regarding the error categorization.  Not too useful.

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

AUTHOR
       Robert Henry

FILES
       ~/.errorrc	   function names to ignore for lint error messages
       /dev/tty 	   user's teletype

BUGS
       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.

       Error, since it is purely mechanical, will not filter  out  subsequent  errors  caused  by
       `floodgating'  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
       alignment of the `|' marking the point of error is also disturbed by error.

       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.

4th Berkeley Distribution		 October 21, 1996				 ERROR(1)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 08:18 PM.