🚀 go-pugleaf

In article <1991Apr27.150844.5719@telesys.cts.com>, kreed@telesys.cts.com (Kevin W. Reed) writes:
|> I have the (I believe) latest and greatest version of Patch,
|> 
|> 	$Header: patch.c,v 2.0.2.0 90/05/01 22:17:50 davison Locked $
|> 	Patch level: 12u3

  I just pulled the source off of jpl-devvax.jpl.nasa.gov, and I assume that
those are the most up-to-date, and this is what they say when you run "patch
-v":

	$Header: patch.c,v 2.0.1.6 88/06/22 20:46:39 lwall Locked $
	Patch level: 12

  It looks to me like someone has made modifications to the version you have. 
I don't know whether or not those modifications will cause the problems you're
having.

|> But seem to have problems when a patch file attempts to create a new
|> file (compared against /dev/null).

  The code does not decide whether or not to create a file by checking to see
if the old file in the patch is /dev/null.  It does so by checking to see if
(a) the patch has only one hunk, with "*** 0 ****" as the contents of the
original file in the hunk, and (b) the new file named in the patch does not
exist.

|> After scanning the sources, it seems
|> that the code to handle this type of occurance is either missing or 
|> been obliterated.

  I found the code that does the checks I mentioned above near the top of the
function plan_a() in the file inp.c in the sources.  Here's the relevant block:

    if (ok_to_create_file && stat(filename, &filestat) < 0) {
	if (verbose)
	    say2("(Creating file %s...)\n",filename);
	makedirs(filename, TRUE);
	close(creat(filename, 0666));
    }

The variable ok_to_create_file is set elsewhere.

|> When a new file is encountered, the program simply
|> asks for "Filename to Patch: " instead of creating the new module.

  I don't know why this is happening.  Like I said, it could be because
whatever changes have been introduced into the version you have, broke the new
file functionality.  Or, it could be because the patch that's trying to create
the new file is broken in some respect.  Or, it could be because of a real bug
in patch :-).  If the code I quoted above does exist in your version, I would
suggest you run it under a debugger and step through the plan_a() function and
see exactly what's going wrong.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710