Command:   patch - patches up a file from the original and a diff
Syntax:    patch [-NRbcdeflnop] [-Fn] [-D label] [file [difflist]]
Flags:     -D  Mark changes  with    #ifdef...#endif    next  arg  gives
               label
           -F  Sets the maximum fuzz factor to n
           -N  Ignore patches that are reversed or already applied
           -R  Reverse the patches
           -b  Next argument is backup extension,  instead  of  using  a
               tilde ( )
           -c  Interpret the patch file as a context diff
           -d  Cd to the next arg (assumed a dir) before doing anything
           -e  Interpret the patch file as an ed script
           -f  Forces patch to do its work without asking any questions
           -l  Do matching loosely (e.g., all white space is equivalent)
           -n  Interpret the patch file as a normal diff
           -o  Next argument is the output file name
           -p  Sets the pathname strip count
Examples:  patch file difflist      # Fix up file
           patch <difflist          # Patch multiple files

     The MINIX user community on USENET frequently makes improvements to
the  MINIX  software.   The  changes  are  distributed  in  the  form of
differences between the original file and the new one, made with  cdiff.
To update the original version (which you must have), use patch.  If the
original file is called prog.c and the patch is  called  prog.cdif  then
you should type:

        patch  prog.c  prog.cdif

In some cases, a large number of files in a  single  directory  will  be
updated  at  once.   In  this  case,  the  difference  file  may  be the
concatenation of many individual difference files.  The  resulting  file
usually has a name like dir.cdif.  To apply all the patches, type:

        patch  <dir.cdif


     Patch will take a patch file containing any of the three  forms  of
difference  listing  produced  by  the  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 a tilde  appended,  or  as
specified  by  the  -b  flag.   You  may also specify where you want the
output to go with a -o flag.  If 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 -c, -e, or -n flag.  Context diffs and
normal diffs are applied by the patch program itself, while ed diffs are
simply fed to the ed editor via a pipe.

     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 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, 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.  As  a  first  guess,  it takes the line number mentioned for the
hunk, plus or minus any offset used in applying the previous  hunk.   If
that  is  not  the  correct  place,  patch  will  scan both forwards and
backwards for a set of lines matching the context  given  in  the  hunk.
First  patch looks for a place where all lines of the context match.  If
no such place is found, and it is 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 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 '#'.  (Note that the rejected hunk will come out in
context diff form whether the input patch was a context diff or a normal
diff.  If  the input was a normal diff, many of the contexts will simply
be null.) The line numbers on the  hunks  in  the  reject  file  may  be
different  than in the patch file: they reflect the approximate location
patch thinks the failed hunks belong in the new file rather than the old
one.

     As each hunk is completed,  you  will  be  told  whether  the  hunk
succeeded  or failed, and which line (in the new file) 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,  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, 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.

     (If the original file cannot be found, but a suitable SCCS  or  RCS
file is handy, patch will attempt to get or check out the file.)

     Additionally, if the leading garbage  contains  a  'Prereq:'  line,
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, patch will ask for confirmation before proceeding.

     If the patch file contains more than one patch, 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
flags (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.)

     Patch recognizes the following flages:

     The -b flag causes the next  argument  to  be  interpreted  as  the
backup extension, to be used in place of the tilde.

     The -B flag 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. This argument is an extension to  Larry  Wall's
patch v2.0.1.4, patchlevel 8, made by M. Greim (greim@sbsvax.uucp).

     The -c flag forces patch to interpret the patch file as  a  context
diff.

     The -d flag causes patch  to  interpret  the  next  argument  as  a
directory, and cd to it before doing anything else.

     The -D flag causes patch to use the '#ifdef...#endif' construct  to
mark   changes.    The   argument   following   will   be  used  as  the
differentiating symbol.  Note that, unlike the C compiler, there must be
a space between the -D and the argument.

     The -e flag forces patch to interpret  the  patch  file  as  an  ed
script.

     The -f flag forces patch to assume that the user knows exactly what
he  or she is doing, and to not ask any questions.  It does not suppress
commentary, however.  Use -s for that.

     The -Fn flag  sets the maximum fuzz factor.  This flag only applies
to  context  diffs,  and causes patch to ignore up to that many lines in
looking for places to install a hunk.  Note that a  larger  fuzz  factor
increases the odds of a faulty patch.  The default fuzz factor is 2, and
it may not be set to more than the number of lines  of  context  in  the
context diff, ordinarily 3.

     The -l flag causes the pattern matching to be done loosely, in case
the  tabs  and spaces have been munged in your input file.  Any sequence
of whitespace in the pattern line will match any sequence in  the  input
file.   Normal  characters  must  still match exactly.  Each line of the
context must still match a line in the input file.

     The -n flag forces patch to interpret the patch file  as  a  normal
diff.

     The -N flag causes patch to  ignore  patches  that  it  thinks  are
reversed or already applied.  See also -R.

     The -o flag causes the next  argument  to  be  interpreted  as  the
output file name.





                                                                        



                                                                        


     The -pn flag sets the pathname  strip  count,  which  controls  how
pathnames found in the patch file are treated, in case the you keep your
files in a different directory than the person who sent out  the  patch.
The  strip  count specifies how many slashes are to be stripped from the
front of the pathname.  (Any intervening directory names also go  away.)
As  a simple example, let us suppose that the filename in the patch file
is /u/howard/src/blurfl/blurfl.c setting -p  or  -p0  gives  the  entire
pathname  unmodified, -p1 gives u/howard/src/blurfl/blurfl.c without the
leading slash, -p4 gives blurfl/blurfl.c and not specifying  -p  at  all
just  gives you blurfl.c.  Whatever you end up with is looked for either
in the current directory, or the directory specified by the -d flag.

     The -r flag causes the next  argument  to  be  interpreted  as  the
reject file name.

     The -R flag tells patch that this patch was created  with  the  old
and  new  files  swapped.   (That does happen occasionally, human nature
being what it is.)  Patch will attempt to swap each hunk  around  before
applying  it.  Rejects will come out in the swapped format.  The -R flag
will not  work  with  ed  diff  scripts  because  there  is  too  little
information to reconstruct the reverse operation.

     If the first hunk of a patch fails, patch will reverse the hunk  to
see  if it can be applied that way.  If it can, you will be asked if you
want to have the -R flag set. If it cannot, the patch will  continue  to
be  applied normally.  (Note: this method cannot detect a reversed patch
if it is a normal diff and if the first command is an  append  (i.e.  it
should have been a delete) since appends always succeed, due to the fact
that a null context will match anywhere.  Luckily, most patches  add  or
change lines rather than delete them, so most reversed normal diffs will
begin with a delete, which will fail, triggering the heuristic.)

     The -s flag makes patch do  its  work  silently,  unless  an  error
occurs.

     The -S flag causes patch to ignore this patch from the patch  file,
but continue on looking for the next patch in the file. Thus

        patch  -S  +  -S  +  <patchfile

will ignore the first and second of three patches.

     The -vflag causes patch to print out its revision header and  patch
level.

     The -xnumber  flag   sets  internal  debugging  flags,  and  is  of
interest only to patch patchers.