neulab/tldr huggingface dataset:
A Third Sample Input File Here is a third sample file that will be used in examples to illustrate the output of diff3 and how various options can change it. The first two files are the same that we used for diff (see Section “Sample diff Input”).  This is the third sample file, called tao:
The Way that can be told of is not the eternal Way; The name that can be named is not the eternal name. The Nameless is the origin of Heaven and Earth; The named is the mother of all things.
Therefore let there always be non-being, so we may see their subtlety, And let there always be being, so we may see their result. The two are the same, But after they are produced, they have different names.
-- The Way of Lao-Tzu, tr. Wing-tsit Chan
Example of diff3(Normal) Format Here is the output of the command diff3 lao tzu tao (see Section “Sample diff3 Input”, for the complete contents of the files). Notice that it shows only the lines that are different among the three files.
====2 1:1,2c 3:1,2c The Way that can be told of is not the eternal Way; The name that can be named is not the eternal name. 2:0a ====1 1:4c The Named is the mother of all things. 2:2,3c 3:4,5c The named is the mother of all things.
====3 1:8c 2:7c so we may see their outcome. 3:9c so we may see their result. ==== 1:11a 2:11,13c They both may be called deep and profound. Deeper and more profound, The door of all subtleties! 3:13,14c
Detailed Description of diff3(Normal) Format Each hunk begins with a line marked ====.  Three-way hunks have plain ==== lines, and two-way hunks have 1, 2, or 3 appended to specify which of the three input files differ in that hunk. The hunks contain copies of two or three sets of input lines each preceded by one or two commands identifying where the lines came from.
Normally, two spaces precede each copy of an input line to distinguish it from the commands. But with the [-T] or [--initial-tab] option, diff3 uses a tab instead of two spaces; this lines up tabs correctly.See Section “Tabs”, for more information.
Commands take the following forms:
file: la This hunk appears after line l of file file, and contains no lines in that file. To edit this file to yield the other files, one must append hunk lines taken from the other files. For example, 1:11a means that the hunk follows line 11 in the first file and contains no lines from that file.
file: rc This hunk contains the lines in the range r of file file.  The range r is a comma-separated pair of line numbers, or just one number if the range is a singleton. To edit this file to yield the other files, one must change the specified lines to be the lines taken from the other files. For example, 2:11,13c means that the hunk contains lines 11 through 13 from the second file.
If the last line in a set of input lines is incomplete (see Section “Incomplete Lines”), it is distinguished on output from a full line by a following line that starts with \.
diff3(Hunks) Groups of lines that differ in two or three of the input files are called diff3 hunks, by analogy with diff hunks (see Section “Hunks”).  If all three input files differ in a diff3 hunk, the hunk is called a three-way hunk ; if just two input files differ, it is a two-way hunk.
As with diff, several solutions are possible. When comparing the files A, B, and C, diff3 normally finds diff3 hunks by merging the two-way hunks output by the two commands diff A B and diff A C.  This does not necessarily minimize the size of the output, but exceptions should be rare.
For example, suppose F contains the three lines a, b, f, G contains the lines g, b, g, and H contains the lines a, b, h.  diff3 F G H might output the following:
====2 1:1c 3:1c a 2:1c g ==== 1:3c f 2:3c g 3:3c h
because it found a two-way hunk containing a in the first and third files and g in the second file, then the single line b common to all three files, then a three-way hunk containing the last line of each file.
Merging From a Common Ancestor When two people have made changes to copies of the same file, diff3 can produce a merged output that contains both sets of changes together with warnings about conflicts.
One might imagine programs with names like diff4 and diff5 to compare more than three files simultaneously, but in practice the need rarely arises. You can use diff3 to merge three or more sets of changes to a file by merging two change sets at a time.
diff3 can incorporate changes from two modified versions into a common preceding version. This lets you merge the sets of changes represented by the two newer files. Specify the common ancestor version as the second argument and the two newer versions as the first and third arguments, like this:
diff3 mine older yours
You can remember the order of the arguments by noting that they are in alphabetical order.
You can think of this as subtracting older from yours and adding the result to mine, or as merging into mine the changes that would turn older into yours.  This merging is well-defined as long as mine and older match in the neighborhood of each such change. This fails to be true when all three input files differ or when only older differs; we call this a conflict. When all three input files differ, we call the conflict an overlap.
diff3 gives you several ways to handle overlaps and conflicts. You can omit overlaps or conflicts, or select only overlaps, or mark conflicts with special <<<<<<< and >>>>>>> lines.
diff3 can output the merge results as an ed script that that can be applied to the first file to yield the merged output.  However, it is usually better to have diff3 generate the merged output directly; this bypasses some problems with ed.
Selecting Which Changes to Incorporate You can select all unmerged changes from older to yours for merging into mine with the [-e] or [--ed] option. You can select only the nonoverlapping unmerged changes with [-3] or [--easy-only], and you can select only the overlapping changes with [-x] or [--overlap-only].
The [-e], [-3] and [-x] options select only unmerged changes, i.e. changes where mine and yours differ; they ignore changes from older to yours where mine and yours are identical, because they assume that such changes have already been merged.  If this assumption is not a safe one, you can use the [-A] or [--show-all] option (see Section “Marking Conflicts”).
Here is the output of the command diff3 with each of these three options (see Section “Sample diff3 Input”, for the complete contents of the files). Notice that [-e] outputs the union of the disjoint sets of changes output by [-3] and [-x].
Output of diff3 -e lao tzu tao:
-- The Way of Lao-Tzu, tr. Wing-tsit Chan . 8c so we may see their result. .
Output of diff3 -3 lao tzu tao:
8c so we may see their result. .
Output of diff3 -x lao tzu tao:
-- The Way of Lao-Tzu, tr. Wing-tsit Chan .
Marking Conflicts diff3 can mark conflicts in the merged output by bracketing them with special marker lines. A conflict that comes from two files A and B is marked as follows:
<<<<<<< A lines from A ======= lines from B >>>>>>> B
A conflict that comes from three files A, B and C is marked as follows:
<<<<<<< A lines from A ||||||| B lines from B ======= lines from C >>>>>>> C
The [-A] or [--show-all] option acts like the [-e] option, except that it brackets conflicts, and it outputs all changes from older to yours, not just the unmerged changes. Thus, given the sample input files (see Section “Sample diff3 Input”), diff3 -A lao tzu tao puts brackets around the conflict where only tzu differs:
<<<<<<< tzu ======= The Way that can be told of is not the eternal Way; The name that can be named is not the eternal name. >>>>>>> tao
And it outputs the three-way conflict as follows:
<<<<<<< lao ||||||| tzu They both may be called deep and profound. Deeper and more profound, The door of all subtleties! =======
-- The Way of Lao-Tzu, tr. Wing-tsit Chan >>>>>>> tao
The [-E] or [--show-overlap] option outputs less information than the [-A] or [--show-all] option, because it outputs only unmerged changes, and it never outputs the contents of the second file. Thus the [-E] option acts like the [-e] option, except that it brackets the first and third files from three-way overlapping changes. Similarly, [-X] acts like [-x], except it brackets all its (necessarily overlapping) changes. For example, for the three-way overlapping change above, the [-E] and [-X] options output the following:
<<<<<<< lao =======
If you are comparing files that have meaningless or uninformative names, you can use the [--label= label] option to show alternate names in the <<<<<<<, ||||||| and >>>>>>> brackets. This option can be given up to three times, once for each input file. Thus diff3 -A --label X --label Y --label Z A B C acts like diff3 -A A B C, except that the output looks like it came from files named X, Y and Z rather than from files named A, B and C.
Generating the Merged Output Directly With the [-m] or [--merge] option, diff3 outputs the merged file directly. This is more efficient than using ed to generate it, and works even with non-text files that ed would reject. If you specify [-m] without an ed script option, [-A] is assumed.
For example, the command diff3 -m lao tzu tao (see Section “Sample diff3 Input” for a copy of the input files) would output the following:
<<<<<<< tzu ======= The Way that can be told of is not the eternal Way; The name that can be named is not the eternal name. >>>>>>> tao The Nameless is the origin of Heaven and Earth; The Named is the mother of all things. Therefore let there always be non-being, so we may see their subtlety, And let there always be being, so we may see their result. The two are the same, But after they are produced, they have different names. <<<<<<< lao ||||||| tzu They both may be called deep and profound. Deeper and more profound, The door of all subtleties! =======
How diff3(Merges) Incomplete Lines With [-m], incomplete lines (see Section “Incomplete Lines”) are simply copied to the output as they are found; if the merged output ends in an conflict and one of the input files ends in an incomplete line, succeeding |||||||, ======= or >>>>>>> brackets appear somewhere other than the start of a line because they are appended to the incomplete line.
Without [-m], if an ed script option is specified and an incomplete line is found, diff3 generates a warning and acts as if a newline had been present.
Saving the Changed File Traditional Unix diff3 generates an ed script without the trailing w and q commands that save the changes. System V diff3 generates these extra commands. GNU diff3 normally behaves like traditional Unix diff3, but with the [-i] option it behaves like System V diff3 and appends the w and q commands.
The [-i] option requires one of the ed script options [-AeExX3], and is incompatible with the merged output option [-m].
Interactive Merging with sdiff With sdiff, you can merge two files interactively based on a side-by-side [-y] format comparison (see Section “Side by Side”).  Use [-o file] or [--output= file] to specify where to put the merged text.See Section “Invoking sdiff”, for more details on the options to sdiff.
Another way to merge files interactively is to use the Emacs Lisp package emerge.  See Section.Dq emerge , for more information.
Specifying diff(Options) to sdiff The following sdiff options have the same meaning as for diff.  See Section.Dq diff Options , for the use of these options.
-a -b -d -i -t -v -B -E -I regexp
--expand-tabs --ignore-blank-lines  --ignore-case --ignore-matching-lines=regexp  --ignore-space-change --ignore-tab-expansion --left-column  --minimal  --speed-large-files --strip-trailing-cr  --suppress-common-lines --tabsize=columns  --text  --version  --width=columns
For historical reasons, sdiff has alternate names for some options. The [-l] option is equivalent to the [--left-column] option, and similarly [-s] is equivalent to [--suppress-common-lines].  The meaning of the sdiff [-w] and [-W] options is interchanged from that of diff: with sdiff, [-w columns] is equivalent to [--width= columns], and [-W] is equivalent to [--ignore-all-space].  sdiff without the [-o] option is equivalent to diff with the [-y] or [--side-by-side] option (see Section “Side by Side”).
Merge Commands Groups of common lines, with a blank gutter, are copied from the first file to the output. After each group of differing lines, sdiff prompts with % and pauses, waiting for one of the following commands. Follow each command with RET.
e       Discard both versions. Invoke a text editor on an empty temporary file, then copy the resulting file to the output.
eb      Concatenate the two versions, edit the result in a temporary file, then copy the edited result to the output.
ed      Like eb, except precede each version with a header that shows what file and lines the version came from.
e1      Edit a copy of the left version, then copy the result to the output.
e2      Edit a copy of the right version, then copy the result to the output.
1       Copy the left version to the output.
q       Quit.
2       Copy the right version to the output.
s       Silently copy common lines.
v       Verbosely copy common lines. This is the default.
The text editor invoked is specified by the EDITOR environment variable if it is set. The default is system-dependent.
Merging with patch patch takes comparison output produced by diff and applies the differences to a copy of the original file, producing a patched version. With patch, you can distribute just the changes to a set of files instead of distributing the entire file set; your correspondents can apply patch to update their copy of the files with your changes.  patch automatically determines the diff format, skips any leading or trailing headers, and uses the headers to determine which file to patch. This lets your correspondents feed a mail message containing a difference listing directly to patch.
patch detects and warns about common problems like forward patches. It saves any patches that it could not apply. It can also maintain a patchlevel.h file to ensure that your correspondents apply diffs in the proper order.
patch accepts a series of diffs in its standard input, usually separated by headers that specify which file to patch. It applies diff hunks (see Section “Hunks”) one by one. If a hunk does not exactly match the original file, patch uses heuristics to try to patch the file as well as it can. If no approximate match can be found, patch rejects the hunk and skips to the next hunk.  patch normally replaces each file f with its new version, putting reject hunks (if any) into f.rej.
See Section.Dq Invoking patch , for detailed information on the options to patch.
Selecting the patch(Input) Format patch normally determines which diff format the patch file uses by examining its contents. For patch files that contain particularly confusing leading text, you might need to use one of the following options to force patch to interpret the patch file as a certain format of diff. The output formats listed here are the only ones that patch can understand.
--context context diff.
--ed    ed script.
--normal normal diff.
--unified unified diff.
Revision Control If a nonexistent input file is under a revision control system supported by patch, patch normally asks the user whether to get (or check out) the file from the revision control system. Patch currently supports RCS, ClearCase and SCCS. Under RCS and SCCS, patch also asks when the input file is read- only and matches the default version in the revision control system.
The [-g num] or [--get= num] option affects access to files under supported revision control systems. If num is positive, patch gets the file without asking the user; if zero, patch neither asks the user nor gets the file; and if negative, patch asks the user before getting the file. The default value of num is given by the value of the PATCH_GET environment variable if it is set; if not, the default value is zero if patch is conforming to POSIX, negative otherwise.See Section “patch and POSIX”.
The choice of revision control system is unaffected by the VERSION_CONTROL environment variable (see Section “Backup Names”).
Applying Imperfect Patches patch tries to skip any leading text in the patch file, apply the diff, and then skip any trailing text. Thus you can feed a mail message directly to patch, and it should work. If the entire diff is indented by a constant amount of white space, patch automatically ignores the indentation. If a context diff contains trailing carriage return on each line, patch automatically ignores the carriage return. If a context diff has been encapsulated by prepending - to lines beginning with - as per ftp://ftp.isi.edu/in-notes/rfc934.txt, patch automatically unencapsulates the input.
However, certain other types of imperfect input require user intervention or testing.
Applying Patches with Changed White Space
Sometimes mailers, editors, or other programs change spaces into tabs, or vice versa. If this happens to a patch file or an input file, the files might look the same, but patch will not be able to match them properly. If this problem occurs, use the [-l] or [--ignore-white-space] option, which makes patch compare blank characters (i.e. spaces and tabs) loosely so that any nonempty sequence of blanks in the patch file matches any nonempty sequence of blanks in the input files. Non-blank characters must still match exactly. Each line of the context must still match a line in the input file.
Applying Reversed Patches
Sometimes people run diff with the new file first instead of second. This creates a diff that is “reversed”.  To apply such patches, give patch the [-R] or [--reverse] option.  patch then attempts to swap each hunk around before applying it. Rejects come out in the swapped format.
Often patch can guess that the patch is reversed. If the first hunk of a patch fails, patch reverses the hunk to see if it can apply it that way. If it can, patch asks you if you want to have the [-R] option set; if it can't, patch continues to apply the patch normally. This method cannot detect a reversed patch if it is a normal diff and the first command is an append (which should have been a delete) since appends always succeed, because a null context matches anywhere. But most patches add or change lines rather than delete them, so most reversed normal diffs begin with a delete, which fails, and patch notices.
If you apply a patch that you have already applied, patch thinks it is a reversed patch and offers to un-apply the patch. This could be construed as a feature. If you did this inadvertently and you don't want to un-apply the patch, just answer n to this offer and to the subsequent “apply anyway” question---or type C-c to kill the patch process.
Helping patch(Find) Inexact Matches
For context diffs, and to a lesser extent normal diffs, patch can detect when the line numbers mentioned in the patch are incorrect, and it attempts to find the correct place to apply each hunk of the patch. As a first guess, it takes the line number mentioned in the hunk, plus or minus any offset used in applying the previous hunk. If that is not the correct place, patch scans both forward and backward 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 it cannot find such a place, and it is reading a context or unified diff, and the maximum fuzz factor is set to 1 or more, then patch makes another scan, ignoring the first and last line of context. If that fails, and the maximum fuzz factor is set to 2 or more, it makes another scan, ignoring the first two and last two lines of context are ignored. It continues similarly if the maximum fuzz factor is larger.
The [-F lines] or [--fuzz= lines] option sets the maximum fuzz factor to lines.  This option only applies to context and unified diffs; it ignores up to lines lines while looking for the place to install a hunk. Note that a larger fuzz factor increases the odds of making a faulty patch. The default fuzz factor is 2; there is no point to setting it to more than the number of lines of context in the diff, ordinarily 3.
If patch cannot find a place to install a hunk of the patch, it writes the hunk out to a reject file (see Section “Reject Names”, for information on how reject files are named). It writes out rejected hunks in context format no matter what form the input patch is in. If the input is a normal or ed diff, many of the contexts are simply null. The line numbers on the hunks in the reject file may be different from those in the patch file: they show the approximate location where patch thinks the failed hunks belong in the new file rather than in the old one.
If the [--verbose] option is given, then as it completes each hunk patch tells you whether the hunk succeeded or failed, and if it failed, on which line (in the new file) patch thinks the hunk should go. If this is different from the line number specified in the diff, it tells you the offset. A single large offset may indicate that patch installed a hunk in the wrong place.  patch also tells you if it used a fuzz factor to make the match, in which case you should also be slightly suspicious.
patch cannot tell if the line numbers are off in an ed script, and can only detect wrong line numbers in a normal diff when it finds a change or delete command. It may have the same problem with a context diff using a fuzz factor equal to or greater than the number of lines of context shown in the diff (typically 3). In these cases, you should probably look at a context diff between your original and patched input files to see if the changes make sense. Compiling without errors is a pretty good indication that the patch worked, but not a guarantee.
A patch against an empty file applies to a nonexistent file, and vice versa.See Section “Creating and Removing”.
patch usually produces the correct results, even when it must make many guesses.  However, the results are guaranteed only when the patch is applied to an exact copy of the file that the patch was generated from.
Predicting what patch(will) do
It may not be obvious in advance what patch will do with a complicated or poorly formatted patch. If you are concerned that the input might cause patch to modify the wrong files, you can use the [--dry-run] option, which causes patch to print the results of applying patches without actually changing any files.  You can then inspect the diagnostics generated by the dry run to see whether patch will modify the files that you expect. If the patch does not do what you want, you can modify the patch (or the other options to patch) and try another dry run. Once you are satisfied with the proposed patch you can apply it by invoking patch as before, but this time without the [--dry-run] option.
Creating and Removing Files Sometimes when comparing two directories, a file may exist in one directory but not the other. If you give diff the [-N] or [--new-file] option, or if you supply an old or new file that is named /dev/null or is empty and is dated the Epoch (1970-01-01 00:00:00 UTC), diff outputs a patch that adds or deletes the contents of this file. When given such a patch, patch normally creates a new file or removes the old file. However, when conforming to POSIX (see Section “patch and POSIX”), patch does not remove the old file, but leaves it empty. The [-E] or [--remove-empty-files] option causes patch to remove output files that are empty after applying a patch, even if the patch does not appear to be one that removed the file.
If the patch appears to create a file that already exists, patch asks for confirmation before applying the patch.
Updating Time Stamps on Patched Files When patch updates a file, it normally sets the file's last-modified time stamp to the current time of day. If you are using patch to track a software distribution, this can cause make to incorrectly conclude that a patched file is out of date. For example, if syntax.c depends on syntax.y, and patch updates syntax.c and then syntax.y, then syntax.c will normally appear to be out of date with respect to syntax.y even though its contents are actually up to date.
The [-Z] or [--set-utc] option causes patch to set a patched file's modification and access times to the time stamps given in context diff headers. If the context diff headers do not specify a time zone, they are assumed to use Coordinated Universal Time (UTC, often known as GMT).
The [-T] or [--set-time] option acts like [-Z] or [--set-utc], except that it assumes that the context diff headers' time stamps use local time instead of UTC. 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. If the context diff headers specify a time zone, this option is equivalent to [-Z] or [--set-utc].
patch normally refrains from setting a file's time stamps if the file's original last-modified time stamp does not match the time given in the diff header, of if the file's contents do not exactly match the patch. However, if the [-f] or [--force] option is given, the file's time stamps are set regardless.
Due to the limitations of the current diff format, patch cannot update the times of files whose contents have not changed. Also, if you set file time stamps to values other than the current time of day, you should also remove (e.g., with make clean) all files that depend on the patched files, so that later invocations of make do not get confused by the patched files' times.
Multiple Patches in a File If the patch file contains more than one patch, and if you do not specify an input file on the command line, patch tries to apply each patch as if they came from separate patch files. This means that it determines the name of the file to patch for each patch, and that it examines the leading text before each patch for file names and prerequisite revision level (see Section “Making Patches”, for more on that topic).
patch uses the following rules to intuit a file name from the leading text before a patch. First, patch takes an ordered list of candidate file names as follows:
•   If the header is that of a context diff, patch takes the old and new file names in the header. A name is ignored if it does not have enough slashes to satisfy the [-p num] or [--strip= num] option. The name /dev/null is also ignored.
•   If there is an Index: line in the leading garbage and if either the old and new names are both absent or if patch is conforming to POSIX, patch takes the name in the Index: line.
•   For the purpose of the following rules, the candidate file names are considered to be in the order (old, new, index), regardless of the order that they appear in the header.
•   If some of the named files exist, patch selects the first name if conforming to POSIX, and the best name otherwise.
•   If patch is not ignoring RCS, ClearCase, and SCCS (see Section “Revision Control”), and no named files exist but an RCS, ClearCase, or SCCS master is found, patch selects the first named file with an RCS, ClearCase, or SCCS master.
•   If no named files exist, no RCS, ClearCase, or SCCS master was found, some names are given, patch is not conforming to POSIX, and the patch appears to create a file, patch selects the best name requiring the creation of the fewest directories.
•   If no file name results from the above heuristics, you are asked for the name of the file to patch, and patch selects that name.
See Section.Dq patch and POSIX , to see whether patch is conforming to POSIX.
Applying Patches in Other Directories The [-d directory] or [--directory= directory] option to patch makes directory directory the current directory for interpreting both file names in the patch file, and file names given as arguments to other options (such as [-B] and [-o]).  For example, while in a mail reading program, you can patch a file in the /usr/src/emacs directory directly from a message containing the patch like this:
| patch -d /usr/src/emacs
Sometimes the file names given in a patch contain leading directories, but you keep your files in a directory different from the one given in the patch.  In those cases, you can use the [-p number] or [--strip= number] option to set the file name strip count to number.  The strip count tells patch how many slashes, along with the directory names between them, to strip from the front of file names. A sequence of one or more adjacent slashes is counted as a single slash. By default, patch strips off all leading directories, leaving just the base file names.
For example, suppose the file name in the patch file is /gnu/src/emacs/etc/NEWS.  Using [-p0] gives the entire file name unmodified, [-p1] gives gnu/src/emacs/etc/NEWS (no leading slash), [-p4] gives etc/NEWS, and not specifying [-p] at all gives NEWS.
patch looks for each file (after any slashes have been stripped) in the current directory, or if you used the [-d directory] option, in that directory.
Backup Files Normally, patch creates a backup file if the patch does not exactly match the original input file, because in that case the original data might not be recovered if you undo the patch with patch -R (see Section “Reversed Patches”).  However, when conforming to POSIX, patch does not create backup files by default.See Section “patch and POSIX”.
The [-b] or [--backup] option causes patch to make a backup file regardless of whether the patch matches the original input. The [--backup-if-mismatch] option causes patch to create backup files for mismatches files; this is the default when not conforming to POSIX. The [--no-backup-if-mismatch] option causes patch to not create backup files, even for mismatched patches; this is the default when conforming to POSIX.
When backing up a file that does not exist, an empty, unreadable backup file is created as a placeholder to represent the nonexistent file.
Backup File Names Normally, patch renames an original input file into a backup file by appending to its name the extension .orig, or ~ if using .orig would make the backup file name too long. The [-z backup-suffix] or [--suffix= backup-suffix] option causes patch to use backup-suffix as the backup extension instead.
Alternately, you can specify the extension for backup files with the SIMPLE_BACKUP_SUFFIX environment variable, which the options override.
patch can also create numbered backup files the way GNU Emacs does. With this method, instead of having a single backup of each file, patch makes a new backup file name each time it patches a file. For example, the backups of a file named sink would be called, successively, sink.~1~, sink.~2~, sink.~3~, etc.
The [-V backup-style] or [--version-control= backup-style] option takes as an argument a method for creating backup file names. You can alternately control the type of backups that patch makes with the PATCH_VERSION_CONTROL environment variable, which the [-V] option overrides. If PATCH_VERSION_CONTROL is not set, the VERSION_CONTROL environment variable is used instead. Please note that these options and variables control backup file names; they do not affect the choice of revision control system (see Section “Revision Control”).
The values of these environment variables and the argument to the [-V] option are like the GNU Emacs version-control variable (see Section “Backup Names”, for more information on backup versions in Emacs). They also recognize synonyms that are more descriptive. The valid values are listed below; unique abbreviations are acceptable.
numbered Always make numbered backups.
existing Make numbered backups of files that already have them, simple backups of the others. This is the default.
simple  Always make simple backups.
You can also tell patch to prepend a prefix, such as a directory name, to produce backup file names.  The [-B prefix] or [--prefix= prefix] option makes backup files by prepending prefix to them. The [-Y prefix] or [--basename-prefix= prefix] prepends prefix to the last file name component of backup file names instead; for example, [-Y ~] causes the backup name for dir/file.c to be dir/~file.c.  If you use either of these prefix options, the suffix-based options are ignored.
If you specify the output file with the [-o] option, that file is the one that is backed up, not the input file.
Options that affect the names of backup files do not affect whether backups are made. For example, if you specify the [--no-backup-if-mismatch] option, none of the options described in this section have any affect, because no backups are made.
Reject File Names The names for reject files (files containing patches that patch could not find a place to apply) are normally the name of the output file with .rej appended (or # if using .rej would make the backup file name too long).
Alternatively, you can tell patch to place all of the rejected patches in a single file. The [-r reject-file] or [--reject-file= reject-file] option uses reject-file as the reject file name.
Messages and Questions from patch patch can produce a variety of messages, especially if it has trouble decoding its input. In a few situations where it's not sure how to proceed, patch normally prompts you for more information from the keyboard. There are options to produce more or fewer messages, to have it not ask for keyboard input, and to affect the way that file names are quoted in messages.
patch exits with status 0 if all hunks are applied successfully, 1 if some hunks cannot be applied, and 2 if there is more serious trouble. When applying a set of patches in a loop, you should check the exit status, so you don't apply a later patch to a partially patched file.
Controlling the Verbosity of patch
You can cause patch to produce more messages by using the [--verbose] option. For example, when you give this option, the message Hmm... indicates that patch is reading text in the patch file, attempting to determine whether there is a patch in that text, and if so, what kind of patch it is.
You can inhibit all terminal output from patch, unless an error occurs, by using the [-s], [--quiet], or [--silent] option.
Inhibiting Keyboard Input
There are two ways you can prevent patch from asking you any questions. The [-f] or [--force] option assumes that you know what you are doing. It causes patch to do the following:
•   Skip patches that do not contain file names in their headers.
•   Patch files even though they have the wrong version for the Prereq: line in the patch;
•   Assume that patches are not reversed even if they look like they are.
The [-t] or [--batch] option is similar to [-f], in that it suppresses questions, but it makes somewhat different assumptions:
•   Skip patches that do not contain file names in their headers (the same as [-f]).
•   Skip patches for which the file has the wrong version for the Prereq: line in the patch;
•   Assume that patches are reversed if they look like they are.
patch(Quoting) Style
When patch outputs a file name in a diagnostic message, it can format the name in any of several ways. This can be useful to output file names unambiguously, even if they contain punctuation or special characters like newlines. The [--quoting-style= word] option controls how names are output. The word should be one of the following:
shell   Quote names for the shell if they contain shell metacharacters or would cause ambiguous output.
c       Quote names as for a C language string.
escape  Quote as with c except omit the surrounding double-quote characters.
You can specify the default value of the [--quoting-style] option with the environment variable QUOTING_STYLE.  If that environment variable is not set, the default value is shell, but this default may change in a future version of patch.
patch(and) the POSIX Standard If you specify the [--posix] option, or set the POSIXLY_CORRECT environment variable, patch conforms more strictly to the POSIX standard, as follows:
•   Take the first existing file from the list (old, new, index) when intuiting file names from diff headers.See Section “Multiple Patches”.
•   Do not remove files that are removed by a diff.See Section “Creating and Removing”.
•   Do not ask whether to get files from RCS, ClearCase, or SCCS.See Section “Revision Control”.
•   Require that all options precede the files in the command line.
•   Do not backup files, even when there is a mismatch.See Section “Backups”.
GNU patch(and) Traditional patch The current version of GNU patch normally follows the POSIX standard.See Section “patch and POSIX”, for the few exceptions to this general rule.
Unfortunately, POSIX redefined the behavior of patch in several important ways. You should be aware of the following differences if you must interoperate with traditional patch, or with GNU patch version 2.1 and earlier.
•   In traditional patch, the [-p] option's operand was optional, and a bare [-p] was equivalent to [-p0].  The [-p] option now requires an operand, and [-p 0] is now equivalent to [-p0].  For maximum compatibility, use options like [-p0] and [-p1].
Also, traditional patch simply counted slashes when stripping path prefixes; patch now counts pathname components. That is, a sequence of one or more adjacent slashes now counts as a single slash. For maximum portability, avoid sending patches containing // in file names.
•   In traditional patch, backups were enabled by default. This behavior is now enabled with the [-b] or [--backup] option.
Conversely, in POSIX patch, backups are never made, even when there is a mismatch. In GNU patch, this behavior is enabled with the [--no-backup-if-mismatch] option, or by conforming to POSIX.
The [-b suffix] option of traditional patch is equivalent to the -b -z suffix options of GNU patch.
•   Traditional patch used a complicated (and incompletely documented) method to intuit the name of the file to be patched from the patch header. This method did not conform to POSIX, and had a few gotchas. Now patch uses a different, equally complicated (but better documented) method that is optionally POSIX-conforming; we hope it has fewer gotchas. The two methods are compatible if the file names in the context diff header and the Index: line are all identical after prefix- stripping. Your patch is normally compatible if each header's file names all contain the same number of slashes.
•   When traditional patch asked the user a question, it sent the question to standard error and looked for an answer from the first file in the following list that was a terminal: standard error, standard output, /dev/tty, and standard input. Now patch sends questions to standard output and gets answers from /dev/tty.  Defaults for some answers have been changed so that patch never goes into an infinite loop when using default answers.
•   Traditional patch exited with a status value that counted the number of bad hunks, or with status 1 if there was real trouble. Now patch exits with status 1 if some hunks failed, or with 2 if there was real trouble.
•   Limit yourself to the following options when sending instructions meant to be executed by anyone running GNU patch, traditional patch, or a patch that conforms to POSIX. Spaces are significant in the following list, and operands are required.
Tips for Making and Using Patches Use some common sense when making and using patches. For example, when sending bug fixes to a program's maintainer, send several small patches, one per independent subject, instead of one large, harder-to-digest patch that covers all the subjects.
Here are some other things you should keep in mind if you are going to distribute patches for updating a software package.
Tips for Patch Producers To create a patch that changes an older version of a package into a newer version, first make a copy of the older and newer versions in adjacent subdirectories.  It is common to do that by unpacking tar archives of the two versions.
To generate the patch, use 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 [-N] option lets the patch create and remove files; [-a] lets the patch update non-text files; [-u] generates useful time stamps and enough context; and [-r] lets the patch update subdirectories. Here is an example command, using Bourne shell syntax:
diff -Naur gcc-3.0.3 gcc-3.0.4
Tell your recipients how to apply the patches. This should include which working directory to use, and which patch options to use; the option -p1 is recommended. Test your procedure by pretending to be a recipient and applying your patches to a copy of the original files.
See Section.Dq Avoiding Common Mistakes , for how to avoid common mistakes when generating a patch.
Tips for Patch Consumers A patch producer should tell recipients how to apply the patches, so the first rule of thumb for a patch consumer is to follow the instructions supplied with the patch.
GNU diff can analyze files with arbitrarily long lines and files that end in incomplete lines. However, older versions of patch cannot patch such files. If you are having trouble applying such patches, try upgrading to a recent version of GNU patch.
Avoiding Common Mistakes When producing a patch for multiple files, apply diff to directories whose names do not have slashes. This reduces confusion when the patch consumer specifies the [-p number] option, since this option can have surprising results when the old and new file names have different numbers of slashes. For example, do not send a patch with a header that looks like this:
diff -Naur v2.0.29/prog/README prog/README --- v2.0.29/prog/README 2002-03-10 23:30:39.942229878 -0800 +++ prog/README 2002-03-17 20:49:32.442260588 -0800
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 2002-03-10 23:30:39.942229878 -0800 +++ v2.0.30/prog/README 2002-03-17 20:49:32.442260588 -0800
Make sure you have specified the file names correctly, either in a context diff header or with an Index: line. Take care to not send out reversed patches, since these make people wonder whether they have already applied the patch.
Avoid sending patches that compare backup file names like README.orig or README~, 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.
To save people from partially applying a patch before other patches that should have gone before it, you can make the first patch in the patch file update a file with a name like patchlevel.h or version.c, which contains a patch level or version number. If the input file contains the wrong version number, patch will complain immediately.
An even clearer way to prevent this problem is to put a Prereq: line before the patch. If the leading text in the patch file contains a line that starts with Prereq:, patch takes the next word from that line (normally a version number) and checks whether the next input file contains that word, preceded and followed by either white space or a newline. If not, patch prompts you for confirmation before proceeding. This makes it difficult to accidentally apply patches in the wrong order.
Generating Smaller Patches The simplest way to generate a patch is to use diff -Naur (see Section “Tips for Patch Producers”), but you might be able to reduce the size of the patch by renaming or removing some files before making the patch. If the older version of the package contains any files that the newer version does not, or if any files have been renamed between the two versions, make a list of rm and mv commands for the user to execute in the old version directory before applying the patch. Then run those commands yourself in the scratch directory.
If there are any files that you don't need to include in the patch because they can easily be rebuilt from other files (for example, TAGS and output from yacc and makeinfo), exclude them from the patch by giving diff the [-x pattern] option (see Section “Comparing Directories”).  If you want your patch to modify a derived file because your recipients lack tools to build it, make sure that the patch for the derived file follows any patches for files that it depends on, so that the recipients' time stamps will not confuse make.
Now you can create the patch using diff -Naur.  Make sure to specify the scratch directory first and the newer directory second.
Add to the top of the patch a note telling the user any rm and mv commands to run before applying the patch. Then you can remove the scratch directory.
You can also shrink the patch size by using fewer lines of context, but bear in mind that patch typically needs at least two lines for proper operation when patches do not exactly match the input files.
Invoking cmp The cmp command compares two files, and if they differ, tells the first byte and line number where they differ or reports that one file is a prefix of the other.  Bytes and lines are numbered starting with 1. The arguments of cmp are as follows:
cmp options... from-file [to-file [from-skip [to-skip]]]
The file name - is always the standard input.  cmp also uses the standard input if one file name is omitted. The from-skip and to-skip operands specify how many bytes to ignore at the start of each file; they are equivalent to the [--ignore-initial= from-skip: to-skip] option.
By default, cmp outputs nothing if the two files have the same contents. If one file is a prefix of the other, cmp prints to standard error a message of the following form:
cmp: EOF on shorter-file
Otherwise, cmp prints to standard output a message of the following form:
from-file to-file differ: char byte-number, line line-number
The message formats can differ outside the POSIX locale. Also, POSIX allows the EOF message to be followed by a blank and some additional information.
An exit status of 0 means no differences were found, 1 means some differences were found, and 2 means trouble.
Options to cmp Below is a summary of all of the options that GNU cmp accepts. Most options have two equivalent names, one of which is a single letter preceded by -, and the other of which is a long name preceded by --.  Multiple single letter options (unless they take an argument) can be combined into a single command line word: [-bl] is equivalent to [-b -l].
--print-bytes Print the differing bytes. Display control bytes as a ^ followed by a letter of the alphabet and precede bytes that have the high bit set with M- (which stands for “meta”).
--help  Output a summary of usage and then exit.
-i skip
--ignore-initial= skip Ignore any differences in the first skip bytes of the input files. Treat files with fewer than skip bytes as if they are empty. If skip is of the form [from-skip: to-skip], skip the first from-skip bytes of the first input file and the first to-skip bytes of the second.
--verbose Output the (decimal) byte numbers and (octal) values of all differing bytes, instead of the default standard output.
-n count
--bytes= count Compare at most count input bytes.
--silent Do not print anything; only return an exit status indicating whether the files differ.
--version Output version information and then exit.
In the above table, operands that are byte counts are normally decimal, but may be preceded by 0 for octal and 0x for hexadecimal.
A byte count can be followed by a suffix to specify a multiple of that count; in this case an omitted integer is understood to be 1. A bare size letter, or one followed by iB, specifies a multiple using powers of 1024. A size letter followed by B specifies powers of 1000 instead. For example, [-n 4M] and [-n 4MiB] are equivalent to [-n 4194304], whereas [-n 4MB] is equivalent to [-n 4000000].  This notation is upward compatible with the http://www.bipm.fr/enus/3_SI/si-prefixes.html for decimal multiples and with the http://physics.nist.gov/cuu/Units/binary.html
The following suffixes are defined. Large sizes like 1Y may be rejected by your computer due to limitations of its arithmetic.
kB      kilobyte: 10^3 = 1000.
KiB     kibibyte: 2^10 = 1024.  K is special: the SI prefix is k and the IEC 60027-2 prefix is Ki, but tradition and POSIX use k to mean KiB.
MB      megabyte: 10^6 = 1,000,000.
MiB     mebibyte: 2^20 = 1,048,576.
GB      gigabyte: 10^9 = 1,000,000,000.
GiB     gibibyte: 2^30 = 1,073,741,824.
TB      terabyte: 10^12 = 1,000,000,000,000.
TiB     tebibyte: 2^40 = 1,099,511,627,776.
PB      petabyte: 10^15 = 1,000,000,000,000,000.
PiB     pebibyte: 2^50 = 1,125,899,906,842,624.
EB      exabyte: 10^18 = 1,000,000,000,000,000,000.