Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-4.1.3)
Apropos / Subsearch:
optional field

ERROR(1)                    General Commands Manual                   ERROR(1)

       error  -  categorize  compiler  error  messages,  insert at responsible
       source file lines

       error [ -n ] [ -s ] [ -q ] [ -v ] [ -t suffixlist ]
     [ -I ignorefile ] [ filename ]

       error analyzes error messages produced by a  number  of  compilers  and
       language  processors.   It replaces the painful, traditional methods of
       scribbling abbreviations of errors on paper, and permits error messages
       and source code to be viewed simultaneously.

       error  looks at error messages, either from the specified file filename
       or from the standard input, and:

       o Determines which language processor produced each error message.

       o Determines the file name and line number of the erroneous line.

       o Inserts the error message into the source file immediately  preceding
         the erroneous line.

       Error  messages that can't be categorized by language processor or con-
       tent are not inserted into any file, but are sent to the standard  out-
       put.  error touches source files only after all input has been read.

       error  is  intended  to be run with its standard input connected with 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,

              tutorial% make -s lint |&& error -q -v

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

       error knows about the error  messages  produced  by:  make(1),  cc(1V),
       cpp(1), as(1), ld(1), lint(1V), and other compilers.  For all languages
       except Pascal, error messages are restricted to one line.   Some  error
       messages  refer  to  more than one line in more than one file, in which
       case error duplicates the error message  and  inserts  it  in  all  the
       appropriate places.

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

       -q   error asks whether the file should be touched.  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  dis-
            carded 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(1) can't be found,
            try ex(1) or ed(1) from standard places.

       -t suffixlist
            Take the following argument as a suffix list.   Files  whose  suf-
            fices  do not appear in the suffix list are not touched.  The suf-
            fix list is dot separated, and `*' wildcards work.  Thus the  suf-
            fix list:


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

       -s   Print out statistics regarding the error categorization.

       error catches interrupt and terminate signals,  and  terminates  in  an
       orderly fashion.

   Action Statements
       error does one of six things with error messages.

                 Some  language  processors  produce  short  errors describing
                 which file they are processing.  Error uses these  to  deter-
                 mine  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/lint/llib-lc and  /usr/lib/lint/llib-port
                 are   discarded,   to   prevent  accidentaly  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  stan-
                 dard output.  The names of functions 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.

       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 are not inserted into any source file.

       file specific
                 Error  messages  that refer to a specific file but to no spe-
                 cific line are written to the standard output when that  file
                 is touched.

       true errors
                 Error messages that can be intuited are candidates for inser-
                 tion into the file to which they refer.

       Only true error messages are inserted into source files.   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 number in the error message.  Each error mes-
       sage is turned into a one line comment for the language, and is  inter-
       nally  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, format the source pro-
       gram so there are no language statements on the same line as the end of
       a comment.

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

       as(1), cc(1V), cpp(1), csh(1), ed(1), ex(1), ld(1), lint(1V),  make(1),

       Opens the tty-device directly for user input.

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

       Changing a language processor's error message format 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

       Pascal error messages belong after the lines affected, error puts  them
       before.  The alignment of the | marking the point of error is also dis-
       turbed 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 hard-
       copy terminals.

                               9 September 1987                       ERROR(1)