allbery@ncoast.UUCP (Brandon Allbery) (10/27/86)
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
guido@mcvax.uucp (Guido van Rossum) (11/04/86)
Just to let you Unix wizards have something to strive for: On MPW, a nicely integrated programming environment for C (and Pascal and assembler) on the Macintosh, with a strong influence from the Unix shell, the following all nicely works together so as to make this trivial to use (i.e., no macros needed, anybody can do it). 1) compiler error message have this form: file "blurfl.c"; line 123 # error: <message text> 2) 'file' is a built in command which starts editing a file in a separate window 3) 'line' is a built in command which moves the cursor to a line number 4) '#' is the shell comment character 5) you can move to any line in any edit window, press 'Enter' (which is a different key than 'Return'), and that line is executed as a shell command (by selecting a text region you can execute the command(s) in a region). This all works together so that you can click with the mouse on the error message, press 'Enter' and voila: you are at the offending line. You wouldn't believe it, but their grep equivalent also does this (I was wondering why it inserted a '#' before each line it found a while...) Now if only it had multiprocessing, I would give up Unix immediately and start writing utilities for MPW instead. (Oh, they have also fixed the problem of firing up a make without having saved your files -- apparently the low level I/O package synchronizes windows and files when necessary. You can also look at the output of a program in a window on its output file... Enthousiastically yours, Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>