Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: grep replacement
Message-ID: <56814@sun.uucp>
Date: 16 Jun 88 17:45:25 GMT
References: <16173@brl-adm.ARPA> <8102@brl-smoke.ARPA>
Sender: news@sun.uucp
Lines: 25

> In any context where I would trust "patch", I would also trust "ed" using
> the output of "diff -e", which is generally much less output.

In many contexts where I would trust "patch" with a context "diff", I would
*NOT* trust "ed" with a "diff -e" any further than I could throw it.

"diff -e" scripts contain line numbers that *must* match the lines in the file
being patched, at least if you're using "ed" - "patch" may be able to figure
out the right line numbers if you're not patching the exact same version of the
source, although I would not be surprised if it didn't, since "diff -e" scripts
don't have the context that makes this easier.

"diff -c" scripts contain the aforementioned context, so that they can be used
to apply patches to source that is *not* identical to the source from which the
"diff"s were made.  This is quite important in many cases.  (I use "diff -c"
and "patch" to merge different streams of changes to a source file, for
example.)

> I recently generated a "diff -c -b" comparison between SVR2 sh
> sources and the BRL version of sh.  The output was larger than
> the concatenation of all the sources.  It was useful for the
> intended purpose (browsing), but would be ludicrous for "patch"ing.

Yes, you can construct examples where "diff -c" output is too big to be
practical.  However, the vast majority of the "diff -c" patches I've seen
distributed are not that big; the context is a big win.