view release on metacpan or  search on metacpan

inc/bin/patch  view on Meta::CPAN

B<SIMPLE>I<_>B<BACKUP>I<_>B<SUFFIX>
Extension  to  use for backup file names instead of
".orig" or "~".

B<VERSION>I<_>B<CONTROL>
Selects when numbered backup files are made.

=head1 SEE ALSO

diff(1), ed(1)

=head1 NOTES FOR PATCH SENDERS

There are several things you should bear in  mind  if  you
are  going to be sending out patches.  First, you can save
people a lot of grief by keeping a patchlevel.h file which
is  patched to increment the patch level as the first diff
in the patch file you send out.  If you put a Prereq: line
in  with the patch, it won't let them apply patches out of
order without some  warning.   Second,  make  sure  you've
specified  the  filenames  right, either in a context diff
header, or with an Index: line.  If you are patching something in a subdirectory, be sure to tell the patch user to
specify a B<-p> switch as needed.  Third, you  can  create  a
file  by  sending  out a diff that compares a null file to
the file you want to create.  This will only work  if  the
file  you want to create doesn't exist already in the target directory.  Fourth, take care not to send out reversed
patches, since it makes people wonder whether they already
applied the patch.  Fifth, while you may be  able  to  get
away  with  putting 582 diff listings into one file, it is
probably wiser to  group  related  patches  into  separate
files in case something goes haywire.

=head1 DIAGNOSTICS

Too many to list here, but generally indicative that I<patch>
couldn't parse your patch file.

The message "Hmm..." indicates that there  is  unprocessed
text  in  the  patch  file and that I<patch> is attempting to
intuit whether there is a patch in that text and,  if  so,
what kind of patch it is.

I<Patch> will exit with a non-zero status if any reject files
were created.  When applying a set of patches in a loop it
behooves  you to check this exit status so you don't apply
a later patch to a partially patched file.

=head1 CAVEATS

I<Patch> cannot tell if the line numbers are  off  in  an  ed
script,  and  can only detect bad line numbers in a normal
diff when it finds a "change" or a  "delete"  command.   A
context  diff  using fuzz factor 3 may have the same problem.  Until a suitable interactive interface is added, you
should probably do a context diff in these cases to see if
the changes made  sense.   Of  course,  compiling  without
errors  is a pretty good indication that the patch worked,
but not always.

I<Patch> usually produces the correct results, even  when  it
has  to  do  a  lot of guessing.  However, the results are
guaranteed to be correct only when the patch is applied to
exactly  the  same  version of the file that the patch was
generated from.

=head1 BUGS

Could  be  smarter  about  partial  matches,   excessively
deviant  offsets  and swapped code, but that would take an
extra pass.

Check patch mode ( B<-C>) will fail if you try to check  several  patches in succession that build on each other.  The
whole code of I<patch> would have to be restructured to  keep
temporary  files  around so that it can handle this situation.

If code has been duplicated (for instance with #ifdef OLDCODE  ... #else ...  #endif), I<patch> is incapable of patch-
ing both versions, and, if it works at  all,  will  likely
patch  the  wrong  one,  and tell you that it succeeded to
boot.

If you apply a patch you've already  applied,  I<patch>  will
think  it  is  a reversed patch, and offer to un-apply the
patch.  This could be construed as a feature.

=head1 COMPATIBILITY

The perl implementation of patch is based on but not entire compatible with the
documentation for GNU patch version 2.1:

=head2 note 1

On systems that do not support long filenames,
GNU patch uses the extension "~" for backup files and the extension "#" for
reject files.
How to know if a system support long filenames?

=head2 note 2

Only new-style context diffs are supported.
What does old-style context diff look like?

=head2 note 3

If the pipe to ed fails, B<patch> will attempt to apply the ed script on its
own.

=head2 note 4

This algorithm differs from the one described in the documentation for GNU
patch, which scans forwards and backwards from the line number mentioned in the
diff (plus any offset used in applying the previous hunk).

=head2 note 5

Rejected hunks in GNU patch all come out as context diffs regardless of the
input diff, and the lines numbers reflect the approximate location GNU patch
thinks the failed hunks belong in the new file rather than the old one.

=head2 note 6

If the original file cannot be found or is read-only, but a suitable SCCS or RCS