src/gnu/usr.bin/patch/pch.c, branch releng/12.4FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F12.42013-09-03T20:03:10ZRemove our hacked GNU patch.2013-09-03T20:03:10ZPedro F. Giffunipfg@FreeBSD.org2013-09-03T20:03:10Zurn:sha1:d3e23b57a1df39e659c46092668d7716fe8d17ad
The old (2.1) GNU patch has outlived its days. The major
local changes have been moved into the less restrictedly
licensed patch(1) we adopted in usr.bin/ .
A much newer version of GNU patch is available in the
ports tree (devel/patch).
Disconnect from the build and remove.
Properly handle input lines containing NUL characters such that pgets()2013-07-02T17:17:42ZDavid E. O'Brienobrien@FreeBSD.org2013-07-02T17:17:42Zurn:sha1:a559a5a94fc7d293c70329b023cd17a19a66978f
accurately fills the read buffer.
Callers of pgets() still mis-process the buffer contents if the read line
contains NUL characters, but this at least makes pgets() accurate.
Make it so that 'patch < FUBAR' and 'patch -i FUBAR' operate the same.2013-07-02T17:09:57ZDavid E. O'Brienobrien@FreeBSD.org2013-07-02T17:09:57Zurn:sha1:07b3f0f7db7ec4cc407a26f20b9f545c92a571e3
The former makes a copy of stdin, but was not accurately putting the
content of stdin into a temp file. This lead to the undercounting
the number of lines in hunks containing NUL characters when reading
from stdin. Thus resulting in "unexpected end of file in patch" errors.
The buffer returned by fgenln is not a "C" string and might not be NUL2009-09-16T19:53:29ZStephane E. Potvinsepotvin@FreeBSD.org2009-09-16T19:53:29Zurn:sha1:68961d1200a9cb6bf3619f292a56b2ea35a048ae
terminated. Make sure that it is before using it.
Reviewed by: marck@
MFC after: 3 days
Add support for diffs generated by Perforce.2009-08-23T12:23:24ZEd Schoutened@FreeBSD.org2009-08-23T12:23:24Zurn:sha1:69eb6d71d0c17236b77a4a3e2eff4078edf2b25e
It basically picks the filenames from the "====" line and strips off the
# revision number.
Change the internal buffer used to store input lines from a static buffer2009-05-08T02:18:46ZStephane E. Potvinsepotvin@FreeBSD.org2009-05-08T02:18:46Zurn:sha1:9ab20e104c725eb316253051ac826d1b5a8d8423
to a dynamically allocated one in order to support input lines of
arbitrary length.
Approved by: kan (mentor)
MFC after: 1 month
Change parts of the source code to make it closer to style(9), mainly2002-05-21T00:44:18ZGarance A Drosehngad@FreeBSD.org2002-05-21T00:44:18Zurn:sha1:d77254e807f16dbbec97ae5a0b892ac707c0e58e
changing indentation and some comments. Main goal is not perfect style,
but just to reduce differences with NetBSD. The object code is exactly
the same after this change as before it (except for assert() statements
which have moved).
Reviewed by: /sbin/md5 on i386
Obtained from: NetBSD
Add many prototypes and ANSI-ize 'patch. Not a complete job of it, but it gets2002-04-28T01:33:45ZGarance A Drosehngad@FreeBSD.org2002-04-28T01:33:45Zurn:sha1:38a1326cad12aa8f57c6acd7498f25503df976c9
our patch to look a little more like NetBSD's, and has the nice characteristic
that the object code is exactly the same after the change as before it (even in
patch.c and pch.c, which have pesky 'assert' statements in them).
Reviewed by: /sbin/md5 on i386, alpha, sparc64
MFC after: 3 days
Modify our 'patch' utility to recognize the2002-04-26T19:01:19ZGarance A Drosehngad@FreeBSD.org2002-04-26T19:01:19Zurn:sha1:5343608723e3db4c25d77d761d99f3db72036166
\ No newline at end of file
line that some versions of diff print out if the last line of the two files
are different, and one of the two files does not have a newline character
on that last line.
This change is still somewhat under discussion in -arch and -standards, but I
want to commit it to -current today so I'd have the chance to MFC it to -stable
before the code freeze for 4.6-release (which would be May 1st).
Note: the related change to 'diff' (so it might *generate* that line) is NOT
expected to be included in 4.6-release. We can debate that change later.
Obtained from: NetBSD (1.13 of basesrc/usr.bin/patch/pch.c, by kristerw)
MFC after: 4 days
Fix patch such that skipping files does not count as a failure.2000-08-02T06:54:21ZKelly Yanceykbyanc@FreeBSD.org2000-08-02T06:54:21Zurn:sha1:d1b04ce6b7bfd4d77ca5ba0d271a9d904107de65
Previously, using -S/--skip, -f/--force, or -t/--batch to skip a patch in
a patchset still registers a failure which causes patch to return a
non-zero exit code. This is particularly undesirable with regards to
ports as there is no way to ignore the non-zero code. (Luckily, we don't
currently have any ports that make use of any of these options.)
The PR (yes, my own) is slightly incorrect: It states that -f does indeed
properly skip patches. It does, but it still sets the failure flag causing
patch to return non-zero.
PR: 19638
Submitted by: kbyanc@posi.net