PC showing a shell prompt on a Linux desktop
Fatmawati Achmad Zaenuri/Shutterstock.com

The Linux patch command lets you transfer the changes from one set of files to another set of files quickly and safely. Learn how to use patch the simple way.

The patch and diff Commands

Imagine you have a text file on your computer. You receive a modified version of that text file from someone else. How do you quickly transfer all of the changes from the modified file to your original file? That’s where patch and diff come into play. patch and diff are found in Linux and other Unix-Like operating systems, such as macOS.

The diff command examines two different versions of a file and lists the differences between them. The differences can be stored in a file called a patch file.

The patch command can read a patch file and use the contents as a set of instructions. By following those instructions, the changes in the modified file are replicated in the original file.

Now imagine that process happening to an entire directory of text files. All in one go. That’s the power of patch.

Sometimes you don’t get sent the modified files. All you get sent is the patch file. Why send dozens of files round when you can send one file, or post one file for easy download?

What do you do with the patch file to actually patch your files? Apart from almost being a tongue-twister, that’s also a good question. We’ll walk you through it in this article.

The patch command is most often used by people working with software source code files, but it works equally well with any set of text files whatever their purpose, source code or not.

RELATED: How to Compare Two Text Files in the Linux Terminal

Our Example Scenario

In this scenario, we are in a directory called work which contains two other directories. One is called working, and the other one is called latest. The working directory holds a set of source code files. The latest directory holds the most recent version of those source code files, some of which have been modified.

To be safe, the working directory is a copy of the current version of the text files. It isn’t the only copy of them.

Finding the Differences Between Two Versions of a File

The diff command finds the differences between two files. Its default action is to list the modified lines in the terminal window.

One file is called slang.c. We’ll compare the version in the working directory to the one in the latest directory.

The -u (unified) option tells diff to also list some of the un-modified text lines from before and after each of the changed sections. These lines are called context lines. They help the patch command locate precisely where a change must be made in the original file.

We provide the names of the files so that diff knows which files to compare. The original file is listed first, then the modified file. This is the command we issue to diff:

diff -u working/slang.c latest/slang.c

diff produces an output listing showing the differences between the files. If the files were identical, there would be no output listed at all. Seeing this type of output from diff confirms that there are differences between the two file versions and that the original file needs patching.

Making a Patch FIle

To capture those differences in a patch file, use the following command. It’s the same command as above, with the output from diff redirected into a file called slang.patch.

diff -u working/slang.c latest/slang.c > slang.patch

The name of the patch file is arbitrary. You can call it anything you like. Giving it a “.patch” extension is a good idea; however, as it does make it clear what type of file it is.

To make patch act upon the patch file and modify the working/slang.c file, use the following command. The -u (unified) option lets patch know that the patch file contains unified context lines. In other words, we used the -u option with diff, so we use the -u option with patch.

patch -u working/slang.c -i slang.patch

If all goes well, there’s a single line of output telling you patch is patching the file.

Making a Backup of the Original FIle

We can instruct patch to make a backup copy of patched files before they are changed by using the -b (backup) option. The -i (input) option tells patch the name of the patch file to use:

patch -u -b working/slang.c -i slang.patch

The file is patched as before, with no visible difference in the output. However, if you look into the working folder, you’ll see that file called slang.c.orig has been created. The date and time stamps of the files show that slang.c.orig is the original file and slang.c is a new file created by patch.

Using diff With Directories

We can use diff to create a patch file that contains all of the differences between the files in two directories. We can then use that patch file with patch to have those differences applied to the files in the working folder with a single command.

The options we’re going to use with diff are the -u (unified context) option we have used earlier, the -r (recursive) option to make diff look into any sub-directories and the -N (new file) option.

The -N option tells diff how to handle files in the latest directory that are not in the working directory. It forces diff to put instructions in the patch file so thatpatch creates files that are present in the latest directory but missing from the working directory.

You can bunch the options together so that they use a single hyphen (-).

Note that we’re only providing the directory names, we’re not telling diff to look at specific files:

diff -ruN working/ latest/ > slang.patch

diff -ruN working/ latest/ > slang.patch

Peeking Inside the Patch File

Let’s have a quick look into the patch file. We’ll use less to look at its contents.

The top of the file shows the differences between the two versions of slang.c.

Scrolling further down through the patch file, we see that it then describes the changes in another file called structs.h. This verifies that the patch file definitely contains the differences between different versions of multiple files.

Look Before You Leap

Patching a large collection of files can be a little unnerving, so we’re going to use the --dry-run option to check everything is fine before we take the plunge and commit ourselves to making the changes.

The --dry-run option tells patch to do everything apart from actually modifying the files. patch will perform all of its pre-flight checks on the files and if it encounters any problems, it reports them. Either way, no files are modified.

If no problems are reported, we can repeat the command without the --dry-run option and confidently patch our files.

The -d (directory) option tell patch which directory to work on.

Note that we’re not using the -i (input) option to tell patch which patch file contains the instructions from diff. Instead, we’re redirecting the patch file into patch with <.

patch --dry-run -ruN -d working < slang.patch

Out of the entire directory, diff found two files to patch. The instructions regarding the modifications for those two files have been checked by patch , and no problems have been reported.

Pre-flight checks are OK; we’re ready for take-off.

Patching a Directory

To genuinely apply the patches to the files we use the previous command without the --dry-run option.

patch -ruN -d working < slang.patch

This time each line of output doesn’t start with “checking,” each line starts with “patching.”

And no problems are reported. We can compile our source code, and we’ll be on the latest version of the software.

Settle Your Differences

This is by far the easiest and safest way to use patch. Copy your target files to a folder and patch that folder. Copy them back when you’re happy that the patching process completed error free.

RELATED: Best Linux Laptops for Developers and Enthusiasts

Profile Photo for Dave McKay Dave McKay
Dave McKay first used computers when punched paper tape was in vogue, and he has been programming ever since. After over 30 years in the IT industry, he is now a full-time technology journalist. During his career, he has worked as a freelance programmer, manager of an international software development team, an IT services project manager, and, most recently, as a Data Protection Officer. His writing has been published by  howtogeek.com, cloudsavvyit.com, itenterpriser.com, and opensource.com. Dave is a Linux evangelist and open source advocate.
Read Full Bio »