[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: gnu diff (was Re: does it really need gnu patch?)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-11-25 00:47:47 CET

"Perry E. Metzger" <perry@piermont.com> writes:

> My one possible guess is that patch is in fact what is failing in the
> test and not actually diff. I'm going to check that. If so, I'll
> figure out what's wrong with our patch and fix it. Otherwise I'll
> continue to be puzzled.

Look at the test in ac-helpers/gnu-diff.sh:

It creates two identical files, each with no newline ending. Then it
appends to one of them, still no newline ending.

Then it runs 'diff'. If I use the 'hacked' GNU diff (/usr/bin/diff)
on FreeBSD, the patch file looks like:

--- foofile Sat Nov 24 17:42:02 2001
+++ foofile2 Sat Nov 24 17:41:53 2001
@@ -1 +1 @@
-fooooextra text
+foooo

But if I run the *real* GNU diff, compiled straight out of diffutils,
the patch file looks like:

--- foofile Sat Nov 24 17:42:02 2001
+++ foofile2 Sat Nov 24 17:41:53 2001
@@ -1 +1 @@
-fooooextra text
\ No newline at end of file
+foooo
\ No newline at end of file

This second patch file causes /usr/bin/patch (Larry Wall, v.2.1) to
choke and claim the patch is malformed. I just verified this by hand.

I'm certain that the FreeBSD folks removed the '\ No newline' output
behavior so that they could go on using Larry Wall's original patch
program. Compare the diffutils source with the BSD source -- you
should see the difference.

Really, I don't see a lot of choices here: either an operating system
needs to use the true-blue GNU diff/patch as a pair, or use the hacked
GNU diff and Larry Wall patch as a pair.

Going out for the evening, back later...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.