Path: utzoo!attcan!uunet!mcvax!ukc!eagle!icdoc!cam-cl!
From: rbj@arpa.icst-cmr (Root Boy Jim)
Newsgroups: comp.unix.wizards
Subject: grep replacement
Message-ID: <8806151545.AA01249@cmr.icst.nbs.gov>
Date: 15 Jun 88 15:45:31 GMT
Sender: unix-wizards-request@uk.ac.ucl.cs.nss
Lines: 61
To: unix-wizards@mil.brl.sem

? From: Randy Orrison <randy@umn-cs.cs.umn.edu>

? In article <7962@alice.UUCP> andrew@alice.UUCP writes:
? |3) print lines with context.
? |	the second most requested feature but i'm not doing it. this is
? |	just the job for sed. to be consistent, we just took the context
? 							^^^^^^^^^^^^^^^^
? |	crap out of diff too. this is actually reasonable; showing context
? 	^^^^^^^^^^^^^^^^
? |	is the job for a separate tool (pipeline difficulties apart).
? 
? 
? What?!?!?   Ok, i would like context in grep, but i'll live without it.
? Context diffs, however are a different matter.  There isn't an easy way
? to generate them with diff/context (the first character of every line is
? produced as part of the diff).  Context diffs are useful for patches, and
? having a tool to generate them is necessary.  They're a logical improvement
? to diff that is more than just context around the changes.
? 
? If you're fixing grep fine, but don't break diff while you're at it.

Ditto. In this day and age, it is unthinkable to generate diffs by
hand.  It is equally unthinkable to apply diffs (patches) by hand as
well. With the inclusion of the fudge factor in patch, context diffs
take on new value. Distrubuting non-context diffs in a source group
should be considered a felony. Context diffs are a feature that have
been proven useful time and time again.

I find it unacceptable to reread a file twice to do what I could do in
one pass. Thus, Doug Gwyn's suggestion of a separate diffc program is
unacceptable as well.

I too can live without context greps; perhaps sed is an answer, altho
it currently works only on one file (multiple files are catenated).
Perhaps awk could use a `nextfile' command and we'd all be happy?).

You are carrying this `tools' approach too far. Gone are the days of
small sizes; few people run on a PDP-11 anymore. Memory and disk space
are cheap these days; the goal is no longer to reduce each program to
it's minimalist set of options and execution size. Composing tools is
as conceptually intimidating to the user as choosing the right option
in the first place.  Often, the tools *don't* compose correctly, and
functions must be accreted into tools that `logically' could be
handled elsewhere, such as ls -C. Provide what the user needs in a
concise form, without having to compose an arcane list of pipelines.
Trade size of executables for execution speed where appropriate.
Unused code is never paged in anyway.
 
? 	-randy
? -- 
? Randy Orrison, Control Data, Arden Hills, MN		randy@ux.acss.umn.edu
? 8-(OSF/Mumblix: Just say NO!)-8	    {ihnp4, seismo!rutgers, sun}!umn-cs!randy
? 	"I consulted all the sages I could find in Yellow Pages,
? 	but there aren't many of them."			-APP

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	My name is in /usr/dict/words. Is yours?