error man page on OPENSTEP

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


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 standard input, and 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, 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 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,

	      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, as,
       ld, lint, pi, pc, and f77.  Error 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 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 processing.  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/lib/llib-lc	and   /usr/lib/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 written 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	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 comments and source  on  the
       same line should be formatted so that language 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  referenced	 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 ``*'' wildcards 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	  May 5, 1986			      ERROR(1)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OPENSTEP

List of man pages available for OPENSTEP

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]
Tweet
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