view release on metacpan or  search on metacpan

inc/bin/patch  view on Meta::CPAN

package Dev::Null;

# Create filehandles that go nowhere.

sub TIEHANDLE { bless \my $null }
sub PRINT {}
sub PRINTF {}
sub WRITE {}
sub READLINE {''}
sub READ {''}
sub GETC {''}




__END__

=head1 NAME

patch - apply a diff file to an original

=head1 SYNOPSIS

B<patch> [options] [origfile [patchfile]] [+ [options] [origfile]]...

but usually just

B<patch> E<lt>patchfile

=head1 DESCRIPTION

I<Patch> will take a patch file containing any  of  the  four
forms  of  difference listing produced by the I<diff> program
and apply those differences to an original file, producing
a patched version.  By default, the patched version is put
in place of the original, with the original file backed up
to  the  same name with the extension ".orig" [see L<"note 1">],
or as  specified
by  the  B<-b>,  B<-B>,  or B<-V> switches.  The extension used for
making backup files may also  be  specified  in  the  B<SIMPLE>I<_>B<BACKUP>I<_>B<SUFFIX>  environment variable, which is overridden by above switches.

If the backup file already exists,  B<patch>  creates  a  new
backup file name by changing the first lowercase letter in
the last component of the file's name into uppercase.   If
there  are  no  more  lowercase  letters  in  the name, it
removes the first character from  the  name.   It  repeats
this  process  until  it  comes up with a backup file that
does not already exist.

You may also specify where you want the output to go  with
a  B<-o> switch; if that file already exists, it is backed up
first.

If I<patchfile> is omitted, or is a hyphen, the patch will be
read from standard input.

Upon  startup, patch will attempt to determine the type of
the diff listing, unless over-ruled by a B<-c>, B<-e>, B<-n>, or B<-u>
switch.  Context diffs [see L<"note 2">], unified diffs,
and normal diffs are applied by the I<patch> program  itself,
while ed diffs are simply fed to the I<ed> editor via a pipe [see L<"note 3">].

I<Patch> will try to skip  any  leading  garbage,  apply  the
diff,  and then skip any trailing garbage.  Thus you could
feed an article or message containing a  diff  listing  to
I<patch>, and it should work.  If the entire diff is indented
by a consistent amount, this will be taken into account.

With context diffs, and to a  lesser  extent  with  normal
diffs, I<patch> can detect when the line numbers mentioned in
the patch are incorrect, and  will  attempt  to  find  the
correct place to apply each hunk of the patch.  A linear search is made  for  a
place  where  all  lines of the context match.
The hunk is applied at the place nearest the line number mentioned in the
diff [see L<"note 4">].
If no such
place is found, and it's a context diff, and  the  maximum
fuzz  factor  is set to 1 or more, then another scan takes
place ignoring the first and last  line  of  context.   If
that  fails,  and  the  maximum fuzz factor is set to 2 or
more, the first two and last  two  lines  of  context  are
ignored,  and  another scan is made.  (The default maximum
fuzz factor is 2.)   If  I<patch>  cannot  find  a  place  to
install  that  hunk of the patch, it will put the hunk out
to a reject file, which normally is the name of the output
file  plus ".rej" [see L<"note 1">].  The format of the
rejected hunk remains unchanged [see L<"note 5">]. 

As  each  hunk  is completed, you will be told whether the
hunk succeeded or failed, and which line (in the new file)
I<patch> thought the hunk should go on.  If this is different
from the line number specified in the  diff  you  will  be
told  the offset.  A single large offset MAY be an indication that a hunk was installed in the  wrong  place.   You
will  also  be  told if a fuzz factor was used to make the
match, in which case you should also  be  slightly  suspicious.

If  no  original  file  is  specified on the command line,
I<patch> will try to figure out from the leading garbage what
the  name of the file to edit is.  In the header of a context diff, the filename is found from lines beginning with
"***" or "---", with the shortest name of an existing file
winning.  Only context diffs have lines like that, but  if
there  is  an  "Index:" line in the leading garbage, I<patch>
will try to use the filename from that line.  The  context
diff  header  takes  precedence over an Index line.  If no
filename can be intuited from  the  leading  garbage,  you
will be asked for the name of the file to patch.

No attempt is made to look up SCCS or RCS files [see L<"note 6">].

Additionally, if the leading garbage contains a "Prereq: "
line,  I<patch>  will  take   the   first   word   from   the
prerequisites  line  (normally a version number) and check
the input file to see if that word can be found.  If  not,
I<patch> will ask for confirmation before proceeding.

The  upshot of all this is that you should be able to say,
while in a news interface, the following:

     | patch -d /usr/src/local/blurfl

and patch a file in the blurfl directory directly from the
article containing the patch.

If the patch file contains more than one patch, I<patch> will
try to apply each of them as if they  came  from  separate
patch  files.   This means, among other things, that it is
assumed that the name of the file to patch must be  determined  for  each diff listing, and that the garbage before
each diff listing will be examined for interesting  things
such  as filenames and revision level, as mentioned previously.  You can give switches (and another  original  file
name)  for the second and subsequent patches by separating
the corresponding argument lists by a '+'.  (The  argument
list  for  a  second or subsequent patch may not specify a
new patch file, however.)

I<Patch> recognizes the following switches:

=over

=item -b or --suffix

causes the next argument to  be  interpreted  as  the
backup  extension,  to be used in place of ".orig" [see L<"note 1">].

=item -B or --prefix

causes the next argument to be interpreted as a  prefix  to  the  backup  file  name. If this argument is
specified any argument from -b will be ignored.

=item -c or --context

forces I<patch> to interpret the patch file as a context
diff.

=item -C or --check

checks  that  the patch would apply cleanly, but does
not modify anything.

=item -d or --directory