Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cwruecmp!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: net.unix-wizards
Subject: Error processing techniques
Message-ID: <1639@ncoast.UUCP>
Date: Sun, 26-Oct-86 20:21:29 EST
Article-I.D.: ncoast.1639
Posted: Sun Oct 26 20:21:29 1986
Date-Received: Tue, 28-Oct-86 02:30:26 EST
References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP> <30ceeabf.809c@apollo.uucp> <747@zeus.UUCP> <8422@sun.uucp> <765@zeus.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: net.unix-wizards
Organization: North Coast Public Access UN*X, Cleveland, OH
Lines: 46

Quoted from <765@zeus.UUCP> ["Re: Seeking a Development Environment (Sun?)"], by bobr@zeus.UUCP (Robert Reed)...
+---------------
| In article <8422@sun.uucp> guy@sun.uucp (Guy Harris) writes:
| >> (UNIX) does not have ... a C compiler which generates error messages
| >> incompatible with standard error postprocessing techniques.  These may all
| >> be bugs...
| >
| >What does "standard error postprocessing techniques" mean?
| 
| I expressed it that way because I didn't want to get into another vi/emacs
| argument.  Vi users use "error" and emacs users (at least gosling/unipress)
| use next-error.  In either case, it is an ad hoc standard (it has been
| propogated to many machines) and it's one more hurtle to hassle (via a
| filter or whatever) when migrating to the machine.
+---------------

Recently I had to do some coding on an Altos 1086 machine.  The C compiler
(presumably a Microsoft C) produces error messages like the following:

filename.c(line) : error message

The machine also had a vi with the :map command.  I set up the following map:

:map g G:s/^\([^(][^(]*\)(\([0-9][0-9]*\)) : .*$/:!vi +\2 \1/^V^M"cdd@c^V^M

This map incurs the expense of two vi's running at the same time, but will
process errors and position you on the line containing the error.  The "g"
command fails at the end of the error list; it also follows the list backwards
to attempt to insure that other line numbers aren't thrown off by fixes that
delete or add lines.  (I also have an initialization map which gets rid of
non-error lines and sticks a banner at the top of the buffer; this banner
serves the dual purpose of identifying the buffer and marking the end of the
error list.  The macro was necessary because the Altos C compiler prints each
file name as it processes it, ALWAYS.)  This kind of macro can be adapted to
any error scheme, as well as "grep" output, etc.  Unfortunately, it's only as
portable as a vi with the :map command is.

++Brandon
-- 
  ---------------- /--/	Brandon S. Allbery		UUCP: decvax!cwruecmp!
 /              / /|\/	Tridelta Industries, Inc.        ncoast!tdi2!brandon
----    -------- /-++	7350 Corporate Blvd.		PHONE: +1 216 974 9210
   /   / /---,  ----	Mentor, Ohio 44060		SYSOP: UNaXcess/ncoast
  /   / /    / /  /	     -- HOME --			 (216) 781-6201 24 hrs.
 /   / /    / /  /	6615 Center St. Apt. A1-105	ARPA:  ncoast!allbery%
----  -----~ ----	Mentor, Ohio 44060-4101		case.CSNET@relay.cs.net