patch is used with the output of diff, the so-called diffs between two items, to make selective changes.
A typical use of patch is to update your copy of a program's source code or HTML file.
A patch file patchfile should contain a difference listing produced by the diff
program. Normally the patched versions replace the original file. Backups can be made; see the -b or --backup option.
The names of the files to be patched are usually taken from the patch file, but if there's just one
file to be patched it can be specified on the command line as originalfile.
Upon startup, patch attempts to determine the type of the diff listing, unless overruled by a
-c (--context), -e (--ed), -n (--normal), or -u (--unified) option. Context
diffs (old-style, new-style, and unified) and normal diffs are applied by the patch program
itself, while ed diffs are simply fed to the ed(1) editor via a pipe.
The most common operation is to apply patch file on a remote server. First you need to transfer the patch to the same directory
where the page reside
Now we have an old file and a patch file in the same directory we can apply this patch file.
patch<myapp.patchfile
While taking backup there may be all ready an backup file. So we need to save multiple backup files without overwriting. There is
-V option which will set the versioning mechanism of the original file. In this example we will use numbered versioning.
patch -b -V numbered < myapp.patch
Patches make sense only if the code has changed very little
You can also create a diff for the whole directory, not just a single file.
To apply such a diffs the syntax is then
patch -p number < patch_name
The number depends on how deep the subdirectory lies below the current
directory. A patch will generally include instructions for where to place it and what number to use.
To create a patch for the while subtree you can use the command:
diff -Naur old_tree new_tree
where old and new identify the old and new root directories of trees that you want to patch
The names old and new should not contain any slashes, or you need to delete then using -p num option when applying
the patch.
Selected Options
-ddir or --directory=dir
Change to the directory dir immediately, before doing anything else.
-ipatchfile or --input=patchfile
Read the patch from patchfile. If patchfile is -, read from standard
input, the default.
-l or --ignore-whitespace
Match patterns loosely, in case tabs or spaces have been munged in your files. Any sequence of one or more blanks in the
patch file matches any sequence in the original file, and sequences of blanks at the ends of lines
are ignored. Normal characters must still match exactly. Each line of the context must still match a line in the original file.
-n or --normal
Interpret the patch file as a normal diff.
-N or --forward
Ignore patches that seem to be reversed or already applied. See also -R.
-ooutfile or --output=outfile
Send output to outfile instead of patching files in place. Do not use this option if outfile is one of the
files to be patched. When outfile is -, send output to standard output, and send any messages that would usually go
to standard output to standard error.
-p num or --strip=num
Strip the smallest prefix containing num leading slashes from each file name found in the
patch file. A sequence of one or more adjacent slashes is counted as a single slash. This controls how file names found in
the patch file are treated, in case you keep your files in a different directory than the person
who sent out the patch. For example, supposing the file name in the patch
file was
/u/howard/src/blurfl/blurfl.c
setting -p0 gives the entire file name 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 option.
-t or --batch
Suppress questions like -f, but make some different assumptions: skip patches whose headers do not contain file names
(the same as -f); skip patches for which the file has the wrong version for the Prereq: line in the
patch; and assume that patches are reversed if they look like they are.
-T or --set-time
Set the modification and access times of patched files from time stamps given in context diff headers, assuming that the
context diff headers use local time. This option is not recommended, because patches using local time cannot easily be used by
people in other time zones, and because local time stamps are ambiguous when local clocks move backwards during daylight-saving
time adjustments. Instead of using this option, generate patches with UTC and use the -Z or --set-utc
option instead.
-u or --unified
Interpret the patch file as a unified context diff.
Validate Patch File Without Applying or Dry run
We may want to only validate or see the result of the patching. There is a option for this feature. We will use --dry-run option
to only emulate patching process but not change any file really.
patch --dry-run < myapp.patch
Some recommedations
From the man page
There are several things you should bear in mind if you are going to be sending out patches.
Create your patch systematically. A good method is the command diff -Naur old new where old and new
identify the old and new directories. The names old and new should not contain any slashes. The diff command's
headers should have dates and times in Universal Time using traditional Unix format, so that patch recipients can use the -Z
or --set-utc option. Here is an example command, using Bourne shell syntax:
LC_ALL=C TZ=UTC0 diff -Naur gcc-2.7 gcc-2.8
Tell your recipients how to apply the patch by telling them which directory to cd to, and which patch options to
use. The option string -Np1 is recommended. Test your procedure by pretending to be a recipient and applying your patch to
a copy of the original files.
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.
You can create a file by sending out a diff that compares /dev/null or an empty file dated the Epoch (1970-01-01 00:00:00
UTC) to the file you want to create. This only works if the file you want to create doesn't exist already in the target directory.
Conversely, you can remove a file by sending out a context diff that compares the file to be deleted with an empty file dated the
Epoch. The file will be removed unless patch is conforming to POSIX and the -E or --remove-empty-files option
is not given. An easy way to generate patches that create and remove files is to use GNU diff's -N or --new-file
option.
If the recipient is supposed to use the -pN option, do not send output that looks like this:
diff -Naur v2.0.29/prog/README prog/README
--- v2.0.29/prog/README Mon Mar 10
15:13:12 1997
+++ prog/README Mon Mar 17 14:58:22 1997
because the two file names have different numbers of slashes, and different versions of patch interpret the file names differently.
To avoid confusion, send output that looks like this instead:
diff -Naur v2.0.29/prog/README v2.0.30/prog/README
--- v2.0.29/prog/README Mon Mar 10
15:13:12 1997
+++ v2.0.30/prog/README Mon Mar 17 14:58:22 1997
Avoid sending patches that compare backup file names like README.orig, since this might confuse patch into patching
a backup file instead of the real file. Instead, send patches that compare the same base file names in different directories, e.g.
old/README and new/README.
Take care not to send out reversed patches, since it makes people wonder whether they already applied the patch.
Try not to have your patch modify derived files (e.g. the file configure where there is a line configure: configure.in
in your makefile), since the recipient should be able to regenerate the derived files anyway. If you must send diffs of derived
files, generate the diffs using UTC, have the recipients apply the patch with the -Z or --set-utc option, and have
them remove any unpatched files that depend on patched files (e.g. with make clean).
While you may be able to get away with putting 582 diff listings into one file, it may be wiser to group related patches into
separate files in case something goes haywire.
Patch
is a command that is used to apply patch files to the files like source code, configuration. Patch files holds the
difference between original file and new file. In order to get the difference or patch we use
diff
tool.
Software is consist of a bunch of source code. The source code is developed by developers and changes in time. Getting
whole new file for each change is not a practical and fast way. So distributing only changes is the best way. The changes
applied to the old file and than new file or patched file is compiled for new version of software.
Now
we will create patch file in this step but we need some simple source code with two different version. We call the source
code file name as
myapp.c
.
#include <stdio.h>
void main(){
printf("Hi poftut");
printf("This is new line as a patch");
}
Now
we will create a patch file named
myapp.patch
.
$ diff -u myapp_old.c myapp.c > myapp.patch
Create
Patch File
We can print
myapp.patch
file
with following command
$ cat myapp.patch
Apply Patch File
Now
we have a patch file and we assume we have transferred this patch file to the system which holds the old source code which
is named
myapp_old.patch
.
We will simply apply this patch file. Here is what the patch file contains
the name of the patched file
the different content
$ patch < myapp.patch
Apply
Patch File
Take Backup Before Applying Patch
One
of the useful feature is taking backups before applying patches. We will use
-b
option
to take backup. In our example we will patch our source code file with
myapp.patch
.
$ patch -b < myapp.patch
Take
Backup Before Applying Patch
The backup name will be the same as source code file just adding the
.orig
extension.
So backup file name will be
myapp.c.orig
Set Backup File Version
While
taking backup there may be all ready an backup file. So we need to save multiple backup files without overwriting. There
is
-V
option
which will set the versioning mechanism of the original file. In this example we will use
numbered
versioning.
$ patch -b -V numbered < myapp.patch
Set
Backup File Version
As we can see from screenshot the new backup file is named as number like
myapp.c.~1~
Validate Patch File Without Applying or Dry run
We
may want to only validate or see the result of the patching. There is a option for this feature. We will use
--dry-run
option
to only emulate patching process but not change any file really.
$ patch --dry-run < myapp.patch
Reverse Patch
Some
times we may need to patch in reverse order. So the apply process will be in reverse. We can use
-R
parameter
for this operation. In the example we will patch
myapp_old.c
rather
than
myapp.c
First, make a copy of the source tree: ## Original source code is in lighttpd-1.4.35/ directory ##
$ cp -R lighttpd-1.4.35/ lighttpd-1.4.35-new/
Cd to lighttpd-1.4.35-new directory and make changes as per your requirements: $ cd lighttpd-1.4.35-new/
$ vi geoip-mod.c
$ vi Makefile
Finally, create a patch with the following command: $ cd ..
$ diff -rupN lighttpd-1.4.35/ lighttpd-1.4.35-new/ > my.patch
You can use my.patch file to patch lighttpd-1.4.35 source code on a different computer/server
using patch command as discussed above: patch -p1
See the man page of patch and other command for more information and usage - bash(1)
First, make a copy of the source tree: ## Original source code is in lighttpd-1.4.35/ directory ##
$ cp -R lighttpd-1.4.35/ lighttpd-1.4.35-new/
Cd to lighttpd-1.4.35-new directory and make changes as per your requirements: $ cd lighttpd-1.4.35-new/
$ vi geoip-mod.c
$ vi Makefile
Finally, create a patch with the following command: $ cd ..
$ diff -rupN lighttpd-1.4.35/ lighttpd-1.4.35-new/ > my.patch
You can use my.patch file to patch lighttpd-1.4.35 source code on a different computer/server
using patch command as discussed above: patch -p1
See the man page of patch and other command for more information and usage - bash(1)
Patch
is a command that is used to apply patch files to the files like source code, configuration. Patch files holds the
difference between original file and new file. In order to get the difference or patch we use
diff
tool.
Software is consist of a bunch of source code. The source code is developed by developers and changes in time. Getting
whole new file for each change is not a practical and fast way. So distributing only changes is the best way. The changes
applied to the old file and than new file or patched file is compiled for new version of software.
Now
we will create patch file in this step but we need some simple source code with two different version. We call the source
code file name as
myapp.c
.
#include <stdio.h>
void main(){
printf("Hi poftut");
printf("This is new line as a patch");
}
Now
we will create a patch file named
myapp.patch
.
$ diff -u myapp_old.c myapp.c > myapp.patch
Create
Patch File
We can print
myapp.patch
file
with following command
$ cat myapp.patch
Apply Patch File
Now
we have a patch file and we assume we have transferred this patch file to the system which holds the old source code which
is named
myapp_old.patch
.
We will simply apply this patch file. Here is what the patch file contains
the name of the patched file
the different content
$ patch < myapp.patch
Apply
Patch File
Take Backup Before Applying Patch
One
of the useful feature is taking backups before applying patches. We will use
-b
option
to take backup. In our example we will patch our source code file with
myapp.patch
.
$ patch -b < myapp.patch
Take
Backup Before Applying Patch
The backup name will be the same as source code file just adding the
.orig
extension.
So backup file name will be
myapp.c.orig
Set Backup File Version
While
taking backup there may be all ready an backup file. So we need to save multiple backup files without overwriting. There
is
-V
option
which will set the versioning mechanism of the original file. In this example we will use
numbered
versioning.
$ patch -b -V numbered < myapp.patch
Set
Backup File Version
As we can see from screenshot the new backup file is named as number like
myapp.c.~1~
Validate Patch File Without Applying or Dry run
We
may want to only validate or see the result of the patching. There is a option for this feature. We will use
--dry-run
option
to only emulate patching process but not change any file really.
$ patch --dry-run < myapp.patch
Reverse Patch
Some
times we may need to patch in reverse order. So the apply process will be in reverse. We can use
-R
parameter
for this operation. In the example we will patch
myapp_old.c
rather
than
myapp.c
A patch file is a text file which contains the differences between two versions of the same file (or same source-tree). Patch file
is created by using diff command.
1. Create a Patch File using diff
To understand this, let us create a small C program named hello.c
#include <stdio.h>
int main() {
printf("Hello World\n");
}
Now, copy the hello.c to hello_new.c
$ cp hello.c hello_new.c
Edit the hello_new.c as shown below to make some small changes:
Use the patch command as shown below to apply the hello.patch to the original hello.c source code.
$ patch < hello.patch
patching file hello.c
The hello.patch file contains the name of the file to be patched. Once the file is patched, both hello.c and hello_new.c will have
the content.
3. Create a Patch From a Source Tree
The above example was so simple that it works only with one file. We will see how to create and apply patch for a complete source
tree by taking "openvpn" source code as example.
I've downloaded 2 version of openvpn, openvpn-2.3.2 and openvpn-2.3.4.
tar -xvzf openvpn-2.3.2.tar.gz
tar -xvzf openvpn-2.3.4.tar.gz
Now we will create the patch using the following command.
Please note that we are executing the command from /usr/src/. The patch file contains all the filenames in absolute path
format( from root ). So when we execute from /usr/src, without the "-p" option, it will not work properly.
-p3 tells the patch command to skip 3 leading slashes from the filenames present in the patch file. In our case, the filename in
patch file is "/usr/src/openvpn-2.3.2/aclocal.m4", since you have given "-p3", 3 leading slashes, i.e. until /usr/src/ is ignored.
5. Take a Backup before Applying the Patch using -b
You can take a backup of the original file before applying the patch command using the -b option as shown below.
$ patch -b < hello.patch
patching file hello.c
Now you will have a file name "hello.c.orig", which is the backup of the original hello.c.
You can also use -V to decide the backup filename format as shown below. Now you will have a file name "hello.c.~1~".
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
David K Hill 07/11/2019 at 4:15 am
Javed 28/12/2019 at 7:16 pm
