patch: Support long context lines.

MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D43850

patch: fix locate_hunk in empty files

if `first_guess' is zero then main() assumes that locate_hunk has failed
and aborts the patch operation. Instead, make sure to return 1 (the
line number) so th

patch: fix locate_hunk in empty files

if `first_guess' is zero then main() assumes that locate_hunk has failed
and aborts the patch operation. Instead, make sure to return 1 (the
line number) so that the patch operation can continue.

Issue originally found by Neels Hofmeyr in the regress suite of the diff
implementation for got, where the tests assume that applying a diff with
`patch' and then again with `patch -R' yields back the original file.

Obtained from: OpenBSD (CVS patch.c,v 1.71)

show more ...

Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/

patch: omit filename if the prompt was ignored

When a file is missing, patch(1) will prompt for a filename to try and
patch it. If we're doing a dry-run, we'll output that the patch to the
source f

patch: omit filename if the prompt was ignored

When a file is missing, patch(1) will prompt for a filename to try and
patch it. If we're doing a dry-run, we'll output that the patch to the
source file was either ignored/failed. If you ignore the prompt in a
dry-run (i.e. just hit enter), we'll output:

X out of X hunks ignored while patching (null)

Let's improve the aesthetics a bit and just omit the last part if the
prompt was ignored:

X out of X hunks ignored

Unfortunately we can't really test this without expect(1) because both
force and batch mode will use the first best guess, which is wiped out
by the "File to patch:" prompt. We could record the initially derived
bestguess there and use *that*, but given that this is only possible in
an interactive session I think it's fine to just omit the filename
rather than adding a fair amount of complexity (which could also break
other scenarios I haven't considered yet)..

Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38179

show more ...

patch(1): give /dev/null patches special treatment

We have a bad habit of duplicating contents of files that are sourced from
/dev/null and applied more than once... take the more sane (in most ways

patch(1): give /dev/null patches special treatment

We have a bad habit of duplicating contents of files that are sourced from
/dev/null and applied more than once... take the more sane (in most ways)
GNU route and complain if the file exists and offer reversal options.

This still falls short a little bit as selecting "don't reverse, apply
anyway" will still give you duplicated file contents. There's probably other
issues as well, but awareness is the first step to happiness.

MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21535

show more ...

MFHead@r345275

MFhead@r344786

Merge ^/head r344549 through r344775.

patch(1): Exit successfully if we're fed a 0-length patch

This change is made in the name of GNU patch compatibility. If GNU patch is
fed a zero-length patch, it will exit successfully with no outpu

patch(1): Exit successfully if we're fed a 0-length patch

This change is made in the name of GNU patch compatibility. If GNU patch is
fed a zero-length patch, it will exit successfully with no output. This is
used in at least one port to date (comms/wsjtx), and we break on this usage.

It seems unlikely that anyone relies on patch(1) calling their completely
empty patch garbage and failing, and GNU compatibility is a plus if it helps
with porting, so make the switch.

Reported by: db
MFC after: 2 weeks

show more ...

Merge ^/head r326936 through r327149.

patch: rejname[] is also -r option buffer, and should be PATH_MAX.

Obtained from: OpenBSD (CVS 1.64)

Merge ^/head r325999 through r326131.

patch(1): don't assume a match if we run out of context to check

Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applica

patch(1): don't assume a match if we run out of context to check

Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applicable. Matching
with fuzz would be attempted and default to a match when we unexpectedly ran
out of context.

This also affected patches with higher levels of context but had limited
actual context due to the hunk being located near the beginning/end of file.

PR: 74127, 223545 (exp-run)
Reviewed by: emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12631

show more ...

Merge ^/head r325505 through r325662.

Revert r325365

r325365 caused several ports to fail to patch correctly. Revert it for the
time being until an exp-run can be completed.

Requested by: antoine
Approved by: emaste (implicit)

Merge ^/head r323559 through r325504.

MFhead@r325383

patch(1): don't assume a match if we run out of context to check

Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applica

patch(1): don't assume a match if we run out of context to check

Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applicable. Matching
with fuzz would be attempted and default to a match when we unexpectedly ran
out of context.

PR: 74127
Reviewed by: emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12631

show more ...

patch(1): replace strnlen() with a simpler strlen().

Small style fix with here.

Pointed out by: kib

Revert r311106:
patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.

This doesn't really work for 32 bit platforms.

Pointed out by: kib

patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.

We can handle such "big data" without much trouble.
Try to do a better job at detecting the rejection cause while here.

MFC

patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.

We can handle such "big data" without much trouble.
Try to do a better job at detecting the rejection cause while here.

MFC after: 2 weeks

show more ...

Adjust a type from r267490.

Independent of the maximum length, the return type for strnlen(3)
is always size_t.

Merge from head

Catch up with head, primarily for the 1.14.4.0 firmware.

Merge ^/head r285341 through r285792.