261 lines
12 KiB
Plaintext
261 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|