[Chapter 33] 33.9 patch: Generalized Updating of Files that Differ

33.9 patch: Generalized Updating of Files that Differ

patch	Like all of Larry Wall's widely used programs (including perl (37.1), a software configuration script called Configure, and the rn news reader), patch betrays a whimsical intelligence of its own. Feed it any kind of diff listing (28.1) (not just an editing script produced with the -e option (28.9)). patch figures out what it needs to do to apply the diff, and updates the file, supplying all the while a breezy commentary on what it's doing:

Like all of Larry Wall's widely used programs (including perl (37.1), a software configuration script called Configure, and the rn news reader), patch betrays a whimsical intelligence of its own. Feed it any kind of diff listing (28.1) (not just an editing script produced with the -e option (28.9)). patch figures out what it needs to do to apply the diff, and updates the file, supplying all the while a breezy commentary on what it's doing:

% patch &amp;lt; testfile.diff
Hmm...  Looks like a normal diff to me...
File to patch: testfile
Patching file testfile using Plan A...
Hunk #1 succeeded at 2.
done

As Larry once noted, patch has done an awful lot to "change the culture of computing." Almost all free software is now updated by means of patches rather than complete new releases. patch is smart enough to discard any leading or trailing garbage (such as mail headers or signatures) so that a program source file can be updated by piping a mail message containing a diff listing between old and new versions directly to patch.

Here are a few of the other things patch is smart enough to do:

Figure out the name of the file to be updated and do it without asking (usually only if the diff file is a context diff (28.3) produced with the -c option).
Look for a suitable SCCS or RCS (20.12) file and check it out, if the filename itself can't be found.
Handle diff listings that don't quite match. This makes it possible for patch to update a file that the recipient has already changed from the one that the diff was based on.
Save any pieces of the diff file that don't end up being used, in a file named by adding the suffix .rej (reject) to the name of the file being patched.
Back up the file that is being patched, appending the suffix .orig to the name of the file being patched.
Recognize that its input may actually apply to several files, and patch each of them separately. So, for example, a whole directory might be updated by a "patch" file that contained diff listings for each of the files in the directory. (By the way, the -d option to patch tells it to cd to a specified directory before starting work.)
Recognize (or at least speculate) that a patch might have been created incorrectly, with the old and new files swapped. Larry says: "Yes, I'm afraid that does happen occasionally, human nature being what it is." patch's -R option will force patch to reverse the sense of the patch; what's really amusing is to see patch suggest that this might be the thing to do, when things seem out of sync.

If you are a programmer, patch is worth studying just to see how much a program can do to anticipate errors, deal with fuzzy input, and in general "make the computer do the dirty work." But if you're a programmer, you doubtless already know about patch....

One last note: patch is so useful that it's been added to many UNIX systems. Check to see if your system has it before installing it from the CD-ROM. [I've seen buggy or crippled versions from software vendors, though. The one on the disc is worth comparing to yours. &ndash;JP]

- TOR


33.8 Batch Editing Gotcha: Editors Bomb on Big Files		33.10 Quick Globals from the Command Line with qsubst