kreed@telesys.cts.com (Kevin W. Reed) (04/27/91)
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
But seem to have problems when a patch file attempts to create a new
file (compared against /dev/null). After scanning the sources, it seems
that the code to handle this type of occurance is either missing or
been obliterated. When a new file is encountered, the program simply
asks for "Filename to Patch: " instead of creating the new module.
It appears that the question for the Filename occurs before the
system even knows that it is being compared against /dev/null.
Does anyone have a version of Patch that can add new files??
This is for a SCO Xenix 386 2.3.2 site (although I doubt it has anything
to do with that)
I've attempted contacting the authors (including Larry Wall) with no
success.
Thanks for the information...
--
Kevin W. Reed TeleSys Development Systems San Diego, CA USA
{nosc,ucsd}!crash!telesys!kreed kreed@telesys.cts.com
TeleSys-II BBS & Development System Primary Number +1 619 483 3890jik@athena.mit.edu (Jonathan I. Kamens) (04/29/91)
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
DOUG@ysub.ysu.edu (Doug Sewell) (04/29/91)
In article <1991Apr27.150844.5719@telesys.cts.com>, kreed@telesys.cts.com (Kevin W. Reed) says: > >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 > That's the current level on prep.ai.mit.edu. Wayne Davison wrote the support for Unified Diffs (the format he distributed trn patches in). There's more information in the ChangeLog, I'm not sure if Larry has endorsed this fix, or if it broke the existing code in any way. > >I've attempted contacting the authors (including Larry Wall) with no >success. > Larry's no longer at JPL. He just posted Perl 4.0, his ID is listed as lwall@netlabs.com. But since he didn't write the current patch, he may not be able to help you out. Unfortunately, I don't know enough about using patch to help you, either. Doug
kos@nd.se (Karl-Olov Serrander ND) (04/30/91)
I have seen this happen when i used "diffc" from comp.sources.unix v01i025. I can send a patch for this but i think you should use gnudiff instead. -- Karl-Olov Serrander Snail: ND Norsk Data AB, S-194 83 Upplands Vasby, Sweden Voice: +46-760-98400 Fax: +46-760-86297 Email: kos@nd.se or mcsun!sunic!nduvf!kos
jan@unikla.ASK.SE (Jan S{ll) (04/30/91)
In article <1991Apr27.150844.5719@telesys.cts.com> kreed@telesys.cts.com (Kevin W. Reed) writes: [Text deleted] >But seem to have problems when a patch file attempts to create a new >file (compared against /dev/null). After scanning the sources, it seems >that the code to handle this type of occurance is either missing or >been obliterated. When a new file is encountered, the program simply >asks for "Filename to Patch: " instead of creating the new module. > [Text deleted] I had the same problems a time ago. Then I installed RCS 5.5 and had to get my hand on a GNU diff (version 1.15). I Installed this on all my system and continued to work. Then one day I made a misstake whan I applied patches to one om my programs. I Guess that it is the Gnu diff that create the right format of diffs for the patch program to creat a new file. -- ======================================================================= Jan Saell, ASK (Administration & SystemKonsult AB), Kumla, Sweden Voice: INT+46 19 82515 jan@ask.se or mcvax!sunic!unikla!jan FAX: INT+46 19 60651
davison@borland.com (Wayne Davison) (04/30/91)
Kevin W. Reed (kreed@telesys.cts.com) writes: >I have the (I believe) latest and greatest version of Patch Yes, patch level 12u3 is definitely the one to be running, as it contains bug fixes and the unified context diff support that aren't in Larry Wall's last release, patch level 12. This version of patch is currently being maintained by David J. MacKenzie (djm@eng.umd.edu), and is usually found wherever GNU sources are hanging out, since GNU diff v1.15 generates the unified context diff format. >[I] seem to have problems when a patch file attempts to create a new >file (compared against /dev/null). The file creation support in unchanged in recent memory. The problem you describe will result from a incorrect context diff header, so it sounds like SCO Xenix's version of diff isn't working right. A correct header lists the old hunk at line number 0. If this is any other number, patch will assume that the file already exists somewhere, and prompt you for the name of the file to patch if it can't find it. The easiest way to fix this is to grab GNU diff v1.15 from an archive site and use it for all your diffing. And while you're at it, give the unified output a try -- you might find it easier to read, as well as more compact. -- \ /| / /|\/ /| /(_) Wayne Davison (_)/ |/ /\|/ / |/ \ davison@borland.com (W A Y N e) wdavison@mcimail.com (447-5895@mcimail.com)
witr@rwwa.COM (Robert Withrow) (05/01/91)
|>[I] seem to have problems when a patch file attempts to create a new |>file (compared against /dev/null). Just as another data point --- I have recently had similar problems with this version of patch. In my case patch asked me what file to patch in a normal (i.e. not a /dev/null) patch. The diffs *were* generated with gnu diff 1.15, and when I tested the patches patch(1) refused to patch one of the files even though it was there, was readable and writable, and diff was able to read it just minutes before. I think patch has a bug. -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
witr@rwwa.COM (Robert Withrow) (05/02/91)
In article <1991May1.004405.25209@rwwa.COM> I wrote: |Just as another data point --- I have recently had similar problems Forget it... I was just being stupid. As was pointed out to me I was simply mis-using patch. Even though I use it at least once a day, I still manage to screw up. Morale: ``Don't forget the -p0''! P.S., the latest version works great! That version is: $Header: patch.c,v 2.0.2.0 90/05/01 22:17:50 davison Locked $ Patch level: 12u3 -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM