Xref: utzoo comp.unix.wizards:9305 comp.unix.questions:7556
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!necntc!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: grep replacement
Summary: AAAAGH!
Message-ID: <1122@X.UUCP>
Date: 9 Jun 88 04:19:00 GMT
References: <7882@alice.UUCP> <5630@umn-cs.cs.umn.edu> <6866@elroy.Jpl.Nasa.Gov> <5007@sdcsvax.UCSD.EDU>
Organization: Servants of the Great White Frog
Lines: 44

Hypothesize for the moment that I would like to have the Subject: lines for
each article in /usr/spool/news/comp/sources/unix.  Many people have proposed
a new flag for the "new grep" (one that functions just like the -one flag does
on "match", the matching program I use (a flag I implemented long ago)).

In article<5007@sdcsvax.UCSD.EDU>,hutch@net1.ucsd.edu(Jim Hutchison) suggests:
> grep pattern file1 ... fileN | head -1
> This should send grep a SIGPIPE as soon as the first line of output
> trickles through the pipe.  This would result in relatively little
> of the file actually being read under most Unix implementations.

Yes, it would result in relatively little of the file being read.  It would
also result in relatively little of the desired output.  Check the problem
space before posting solutions, folks.

As I pointed out in another message, you can get awk to solve the problem
almost exactly, with some irregularity in the NFILES={0,1} cases.  However,
the "tool-using" approach is a two-edged sword, it seems to me:  a matching
problem should be solvable by using the matching tool, not by a special case
of an editor tool (the purported "sed" solution) or by having to reach for
a full-blown programming language (awk); just as one should not paginate
a text file by using the /PAGINATE /NOPRINT features of a line-printer
program...  Sometimes you need to EN-feature a program in order to avoid
having to turn to (other) inappropriate tools.  "Oh, you can't ADD text
with this editor, only change existing text.  You add text by using
'cat >> filename' ..."

I like the "context" tool suggested elsewhere, but it has one problem (as
stated) for replacing context diffs:  context diffs are both context and
_differences_, and are generally clearly marked as such (i.e., the !+-
convention); while I guess you could turn an ed-script style diff listing
into a context diff (given both input files and the diff marks), that is
a radically different input language than that proposed for eliminating
context grep.  This just means, however, that two context tools are needed,
not just one.

To paraphrase Einstein, "Programs should be as simple as possible, and no
simpler."
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

No amount of "Scotch-Guard" can repel the ugly stains left by REALITY...
		- Griffy