LIBOF

Handbücher für die Kommandozeile

Man » Patch-Handbuch online - Detaillierte Online-Dokumentation für die Patch-Manpage

🌍 ☰ 
patch - Wendet eine Diff-Datei auf ein Original an.

SYNOPSIS

patch [Optionen] [Originaldatei [Patchdatei]]

Normalerweise jedoch:

patch -pnum <Patchdatei>

BESCHREIBUNG

patch nimmt eine Patch-Datei (patchfile) mit einer Differenzliste entgegen, die vom Programm diff erstellt wurde, und wendet diese Unterschiede auf eine oder mehrere Originaldateien an, um gepatchte Versionen zu erstellen. Normalerweise werden die gepatchten Versionen anstelle der Originale gespeichert. Es können Sicherungskopien erstellt werden; siehe die Option -b oder --backup. Die Namen der zu patchenden Dateien werden normalerweise aus der Patch-Datei entnommen, aber wenn nur eine Datei gepatcht werden soll, kann diese auf der Befehlszeile als Originaldatei angegeben werden.

Beim Start versucht patch, den Typ der Diff-Liste zu bestimmen, es sei denn, dies wird durch eine der Optionen -c (--context), -e (--ed), -n (--normal) oder -u (--unified) außer Kraft gesetzt. Kontext-Diffs (alt, neu und vereinheitlicht) und normale Diffs werden vom Patch-Programm selbst angewendet, während Ed-Diffs einfach über eine Pipe an den Editor ed(1) weitergeleitet werden.

Patch versucht, allen vorangestellten oder nachgestellten Müll zu überspringen, die Diff anzuwenden und dann allen vorangestellten oder nachgestellten Müll zu überspringen. So können Sie beispielsweise eine E-Mail-Nachricht mit einer Diff-Liste an patch übergeben, und es sollte funktionieren. Wenn die gesamte Diff-Liste um einen bestimmten Betrag eingerückt ist, wenn die Zeilen mit CRLF enden oder wenn eine Diff-Liste ein oder mehrmals durch das Hinzufügen von "- " zu Zeilen, die mit "-" beginnen, wie in Internet RFC 934 angegeben, gekapselt ist, wird dies berücksichtigt. Nachdem die Einrückung oder Kapselung entfernt wurde, werden Zeilen, die mit # beginnen, ignoriert, da sie als Kommentare betrachtet werden.

Bei Kontext-Diffs und in geringerem Maße bei normalen Diffs kann patch erkennen, wann die in der Patch-Datei angegebenen Zeilennummern falsch sind, und versucht, die richtige Stelle zum Anwenden jedes Patch-Blocks zu finden. Als erste Schätzung nimmt es die in der Patch-Datei angegebene Zeilennummer plus oder minus einem Offset, der beim Anwenden des vorherigen Blocks verwendet wurde. Wenn dies nicht die richtige Stelle ist, durchsucht patch sowohl vorwärts als auch rückwärts nach einer Reihe von Zeilen, die dem im Block angegebenen Kontext entsprechen. Zuerst sucht patch nach einer Stelle, an der alle Zeilen des Kontexts übereinstimmen. Wenn keine solche Stelle gefunden wird und es sich um einen Kontext-Diff handelt und der maximale Fuzz-Faktor auf 1 oder mehr gesetzt ist, wird eine weitere Suche durchgeführt, bei der die erste und letzte Zeile des Kontexts ignoriert werden. Wenn dies fehlschlägt und der maximale Fuzz-Faktor auf 2 oder mehr gesetzt ist, werden die ersten beiden und die letzten beiden Zeilen des Kontexts ignoriert, und eine weitere Suche wird durchgeführt. (Der Standard-maximale Fuzz-Faktor ist 2.)

Blöcke mit weniger Präfix-Kontext als Suffix-Kontext (nach Anwendung von Fuzz) müssen am Anfang der Datei angewendet werden, wenn ihre erste Zeilennummer 1 ist. Blöcke mit mehr Präfix-Kontext als Suffix-Kontext müssen am Ende der Datei angewendet werden.

Wenn ein Patch einen Ort, an dem er einen Abschnitt des Patches installieren kann, nicht finden kann, gibt er diesen Abschnitt in eine Ablehnungsdatei aus, deren Name normalerweise der Name der Ausgabedatei mit dem Suffix .rej oder # ist, wenn .rej einen Dateinamen erzeugt, der zu lang ist (wenn selbst das Anhängen des einzelnen Zeichens # den Dateinamen zu lang macht, wird # durch das letzte Zeichen des Dateinamens ersetzt).

Der abgelehnte Abschnitt wird im Unified- oder Kontext-Diff-Format ausgegeben. Wenn die Eingabe ein normales Diff war, sind viele der Kontexte einfach leer. Die Zeilennummern der Abschnitte in der Ablehnungsdatei können sich von denen in der Patch-Datei unterscheiden: Sie spiegeln die ungefähre Position wider, an der Patch glaubt, dass die fehlgeschlagenen Abschnitte in der neuen Datei platziert werden sollten, und nicht in der alten.

Während jeder Abschnitt verarbeitet wird, werden Sie benachrichtigt, ob der Abschnitt fehlgeschlagen ist, und wenn ja, in welcher Zeile (in der neuen Datei) Patch glaubt, dass der Abschnitt platziert werden sollte. Wenn ein Abschnitt in einer anderen Zeile als der in dem Diff angegebenen Zeile installiert wird, wird Ihnen die Abweichung mitgeteilt. Eine große Abweichung kann darauf hindeuten, dass ein Abschnitt am falschen Ort installiert wurde. Ihnen wird auch mitgeteilt, ob ein Fuzzy-Faktor verwendet wurde, um die Übereinstimmung zu erzielen, und in diesem Fall sollten Sie ebenfalls etwas misstrauisch sein. Wenn die Option --verbose angegeben wird, werden Ihnen auch Abschnitte angezeigt, die exakt übereinstimmen.

Wenn keine Originaldatei origfile in der Befehlszeile angegeben wird, versucht Patch, anhand der einleitenden Informationen den Namen der zu bearbeitenden Datei zu ermitteln, und verwendet dabei die folgenden Regeln.

Zuerst erstellt Patch eine geordnete Liste von Kandidaten-Dateinamen wie folgt:

Wenn der Header der eines Kontext-Diff ist, nimmt Patch die alten und neuen Dateinamen im Header. Ein Name wird ignoriert, wenn er nicht genügend Schrägstriche enthält, um die Option -pnum oder --strip=num zu erfüllen. Der Name /dev/null wird ebenfalls ignoriert.

Wenn es eine Zeile Index: in den einleitenden Informationen gibt und entweder die alten und neuen Namen fehlen oder Patch dem POSIX-Standard entspricht, nimmt Patch den Namen in der Zeile Index: an.

Für die folgenden Regeln werden die Kandidaten-Dateinamen in der Reihenfolge (alt, neu, Index) betrachtet, unabhängig von der Reihenfolge, in der sie im Header erscheinen.

Anschließend wählt Patch einen Dateinamen aus der Kandidatenliste wie folgt aus:

Wenn einige der benannten Dateien vorhanden sind, wählt Patch den ersten Namen, wenn er dem POSIX-Standard entspricht, und den besten Namen, wenn nicht.

Wenn Patch RCS, ClearCase, Perforce und SCCS nicht ignoriert (siehe die Option -g num oder --get=num) und keine benannten Dateien vorhanden sind, aber ein RCS-, ClearCase-, Perforce- oder SCCS-Master gefunden wird, wählt Patch die erste benannte Datei mit einem RCS-, ClearCase-, Perforce- oder SCCS-Master.

Wenn keine benannten Dateien vorhanden sind, kein RCS-, ClearCase-, Perforce- oder SCCS-Master gefunden wurde, einige Namen angegeben sind, Patch nicht dem POSIX-Standard entspricht und der Patch scheinbar eine Datei erstellt, wählt Patch den besten Namen aus, der die Erstellung der wenigsten Verzeichnisse erfordert.

Wenn aus den oben genannten Heuristiken kein Dateiname resultiert, werden Sie nach dem Namen der zu
patchenden Datei gefragt, und patch wählt diesen Namen aus.

Um die beste Datei aus einer nicht leeren Liste von Dateinamen zu ermitteln, wählt patch zunächst alle
Dateien mit der geringsten Anzahl von Pfadkomponenten aus; von diesen wählt es dann alle Dateien mit
dem kürzesten Basisnamen aus; von diesen wählt es dann alle kürzesten Namen aus; schließlich wählt es
den ersten verbleibenden Namen aus.

Zusätzlich nimmt patch, falls der einleitende "Müll" eine Zeile mit Prereq: enthält, das erste Wort aus
der Zeile mit den Voraussetzungen (normalerweise eine Versionsnummer) und überprüft die ursprüngliche
Datei, um festzustellen, ob dieses Wort gefunden werden kann. Wenn dies nicht der Fall ist, fordert
patch eine Bestätigung an, bevor es fortfährt.

Das Ergebnis all dessen ist, dass Sie in der Lage sein sollten, etwas wie den folgenden Shell-Befehl
auszuführen: 

    patch -d /usr/src/local/blurfl

    und eine Datei im Verzeichnis `blurfl` direkt aus einem Patch anwenden, der von der Standardeingabe                                                                                                         
    gelesen wird.

Wenn die Patch-Datei mehr als einen Patch enthält, versucht patch, jeden einzelnen anzuwenden, als ob er
aus separaten Patch-Dateien stammen würde. Das bedeutet unter anderem, dass davon ausgegangen wird,
dass der Name der zu patchenden Datei für jeden Diff-Eintrag bestimmt werden muss und dass der "Müll" vor jedem Diff-Eintrag interessante Informationen wie Dateinamen und Revisionsnummern enthält, wie bereits erwähnt.

OPTIONEN

    -b oder --backup

Erstellt Sicherungskopien von Dateien. Das heißt, beim Patchen einer Datei wird die ursprüngliche Datei umbenannt oder kopiert, anstatt sie zu löschen. Details dazu, wie die Namen der Sicherungsdateien ermittelt werden, finden Sie in der Option -V oder --version-control.

    --backup-if-mismatch

Erstellt eine Sicherungskopie einer Datei, wenn der Patch nicht exakt mit der Datei übereinstimmt und keine Sicherungskopien ansonsten angefordert werden. Dies ist der Standard, es sei denn, patch entspricht POSIX.

    --no-backup-if-mismatch

Erstellt keine Sicherungskopie einer Datei, wenn der Patch nicht exakt mit der Datei übereinstimmt und keine Sicherungskopien ansonsten angefordert werden. Dies ist der Standard, wenn patch POSIX entspricht.

    -B pref oder --prefix=pref

Verwendet die einfache Methode, um die Namen von Sicherungsdateien zu bestimmen (siehe die Option -V oder --version-control), und hängt pref an einen Dateinamen an, wenn die Sicherungsdatei generiert wird. Zum Beispiel ist der einfache Name der Sicherungsdatei für src/patch/util.c mit -B /junk/ /junk/src/patch/util.c.

    --binary

Schreibt alle Dateien im Binärmodus, mit Ausnahme der Standardausgabe und /dev/tty. Beim Lesen wird die Heuristik zum Transformieren von CRLF-Zeilenenden in LF-Zeilenenden deaktiviert. Diese Option ist auf POSIX-Systemen erforderlich, wenn Patches, die auf nicht-POSIX-Systemen generiert wurden, auf nicht-POSIX-Dateien angewendet werden. (Auf POSIX-Systemen werden Zeilenenden beim Lesen und Schreiben von Dateien nie transformiert. Auf Windows werden Zeilenenden standardmäßig beim Lesen und Schreiben transformiert, und Patches sollten mit diff --binary generiert werden, wenn Zeilenenden wichtig sind.)

    -c oder --context

Interpretiert die Patch-Datei als einen normalen Kontext-Diff.

    -d dir oder --directory=dir

Wechselt sofort in das Verzeichnis dir, bevor irgendetwas anderes unternommen wird.

-D define  oder  --ifdef=define

Den Konstrukt #ifdef ... #endif verwenden, um Änderungen zu markieren, mit define als unterscheidendem Symbol.

--dry-run

Die Ergebnisse der Anwendung der Patches ausgeben, ohne tatsächlich Dateien zu ändern.

-e  oder  --ed

Die Patch-Datei als ed-Skript interpretieren.

-E  oder  --remove-empty-files

Ausgabedateien entfernen, die nach dem Anwenden der Patches leer sind. Normalerweise ist diese Option unnötig, da patch die Zeitstempel im Header untersuchen kann, um festzustellen, ob eine Datei nach dem Patchen existieren sollte. Wenn die Eingabe jedoch kein Kontext-Diff ist oder wenn patch POSIX-konform ist, entfernt patch keine leeren gepatchten Dateien, es sei denn, diese Option wird angegeben. Wenn patch eine Datei entfernt, versucht es auch, alle leeren übergeordneten Verzeichnisse zu entfernen.

-f  oder  --force

Annehmend, dass der Benutzer genau weiß, was er tut, und keine Fragen stellen. Patches überspringen, deren Header nicht angeben, welche Datei gepatcht werden soll; Dateien patchen, obwohl sie die falsche Version für die Prereq:-Zeile im Patch haben; und annehmen, dass Patches nicht umgekehrt sind, selbst wenn sie so aussehen. Diese Option unterdrückt keine Kommentare; verwenden Sie -s dafür.

-F num  oder  --fuzz=num

Den maximalen Fuzz-Faktor setzen. Diese Option gilt nur für Diffs mit Kontext und veranlasst patch, bis zu dieser Anzahl von Kontextzeilen zu ignorieren, wenn nach Stellen zum Installieren eines Hunk gesucht wird. Beachten Sie, dass ein größerer Fuzz-Faktor die Wahrscheinlichkeit eines fehlerhaften Patches erhöht. Der Standard-Fuzz-Faktor ist 2. Ein Fuzz-Faktor größer oder gleich der Anzahl der Kontextzeilen im Kontext-Diff, gewöhnlich 3, ignoriert den gesamten Kontext.

-g num  oder  --get=num

Diese Option steuert die Aktionen von patch, wenn eine Datei unter RCS- oder SCCS-Kontrolle steht und nicht existiert oder schreibgeschützt ist und mit der Standardversion übereinstimmt, oder wenn eine Datei unter ClearCase- oder Perforce-Kontrolle steht und nicht existiert. Wenn num positiv ist, holt (oder checked) patch die Datei aus dem Revisionskontrollsystem aus; wenn null, ignoriert patch RCS, ClearCase, Perforce und SCCS und holt die Datei nicht; und wenn negativ, fragt patch den Benutzer, ob die Datei geholt werden soll. Der Standardwert dieser Option wird durch den Wert der Umgebungsvariable PATCH_GET angegeben, falls diese gesetzt ist; wenn nicht, ist der Standardwert null.

--help

Eine Zusammenfassung der Optionen ausgeben und beenden.

-i patchdatei  oder  --input=patchdatei

Den Patch aus patchdatei lesen. Wenn patchdatei - ist, von der Standardeingabe lesen, die Voreinstellung.

-l  oder  --ignore-whitespace

Muster lose abgleichen, falls Tabulatoren oder Leerzeichen in Ihren Dateien verfälscht wurden. Jede Sequenz von einem oder mehreren Leerzeichen in der Patch-Datei entspricht einer beliebigen Sequenz in der Originaldatei, und Leerzeichensequenzen an den Zeilenenden werden ignoriert. Normale Zeichen müssen weiterhin genau übereinstimmen. Jede Kontextzeile muss weiterhin einer Zeile in der Originaldatei entsprechen.

--merge oder --merge=merge oder --merge=diff3

Eine Patch-Datei ähnlich wie diff3(1) oder merge(1) in die Originaldateien einfügen. Wenn ein Konflikt gefunden wird, gibt patch eine Warnung aus und klammert den Konflikt mit <<<<<<< und >>>>>>> Zeilen ein. Ein typischer Konflikt sieht so aus:

<<<<<<<
Zeilen aus der ursprünglichen Datei
|||||||
ursprüngliche Zeilen aus dem Patch
=======
neue Zeilen aus dem Patch
>>>>>>>

Die optionale Option --merge bestimmt das Ausgabeformat für Konflikte: das Diff3-Format zeigt den Abschnitt ||||||| mit den ursprünglichen Zeilen aus dem Patch; im Merge-Format fehlt dieser Abschnitt. Das Merge-Format ist die Standardeinstellung.

Diese Option impliziert --forward und berücksichtigt die Option --fuzz=num nicht.

-n oder --normal

Interpretiert die Patch-Datei als normalen Diff.

-N oder --forward

Wenn ein Patch nicht angewendet werden kann, prüft patch normalerweise, ob der Patch bereits angewendet wurde, indem es versucht, den ersten Block rückwärts anzuwenden. Die Option --forward verhindert dies. Siehe auch -R.

-o outfile oder --output=outfile

Sendet die Ausgabe an die Datei outfile anstatt die Dateien direkt zu patchen. Verwenden Sie diese Option nicht, wenn outfile eine der zu patchenden Dateien ist. Wenn outfile - ist, wird die Ausgabe an die Standardausgabe gesendet, und alle Meldungen, die normalerweise an die Standardausgabe gesendet würden, werden an die Standardfehlerausgabe gesendet.

-pnum oder --strip=num

Entfernt den kleinsten Präfix, der num führende Schrägstriche aus jedem Dateinamen enthält, der in der Patch-Datei gefunden wird. Eine Folge von einem oder mehreren angrenzenden Schrägstrichen wird als ein einzelner Schrägstrich gezählt. Dies steuert, wie Dateinamen, die in der Patch-Datei gefunden werden, behandelt werden, falls Sie Ihre Dateien in einem anderen Verzeichnis speichern als die Person, die den Patch gesendet hat. Wenn der Dateiname in der Patch-Datei beispielsweise lautet:

/u/howard/src/blurfl/blurfl.c

gibt -p0 den gesamten Dateinamen unverändert an, -p1 gibt

u/howard/src/blurfl/blurfl.c

ohne den führenden Schrägstrich an, -p4 gibt

blurfl/blurfl.c

an, und wenn Sie -p nicht angeben, erhalten Sie einfach blurfl.c. Was auch immer Sie am Ende erhalten, wird entweder im aktuellen Verzeichnis oder im Verzeichnis gesucht, das mit der Option -d angegeben wird.

--posix

Hält sich strikter an den POSIX-Standard, wie folgt:

Verwendet die erste vorhandene Datei aus der Liste (alt, neu, Index), wenn Dateinamen aus Diff-Headern abgeleitet werden.

Entfernt keine Dateien, die nach dem Patchen leer sind.

Fragt nicht, ob Dateien aus RCS, ClearCase, Perforce oder SCCS abgerufen werden sollen.

Erfordert, dass alle Optionen den Dateien in der Befehlszeile vorangestellt sind.

Erstellt keine Sicherungskopien von Dateien, wenn es eine Abweichung gibt.

--quoting-style=word

Verwendet den Stil word für die Ausgabe von Dateinamen. Das Wort sollte eines der folgenden sein:

literal

Gibt Dateinamen unverändert aus.

shell

Zitiert Dateinamen für die Shell, wenn sie Shell-Metazeichen enthalten oder eine mehrdeutige Ausgabe verursachen würden.

shell-always

Zitiert Dateinamen für die Shell, auch wenn sie normalerweise keine Zitate benötigen würden.

c

Zitiert Dateinamen, wie es für eine C-Sprachzeichenfolge der Fall wäre.

escape

Zitiert wie bei c, lässt jedoch die umgebenden Anführungszeichen weg.

Sie können den Standardwert der Option --quoting-style mit der Umgebungsvariablen QUOTING_STYLE festlegen. Wenn diese Umgebungsvariable nicht gesetzt ist, ist der Standardwert shell.

-r rejectfile oder --reject-file=rejectfile
Platziert abgelehnten Abschnitten in der Datei rejectfile, anstatt in der Standarddatei .rej. Wenn rejectfile -, werden die abgelehnten Abschnitte verworfen.

-R oder --reverse
Geht davon aus, dass dieser Patch mit den alten und neuen Dateien vertauscht erstellt wurde. (Ja, das kommt gelegentlich vor, menschliche Natur ist nun mal, was sie ist.) Patch versucht, jeden Abschnitt umzukehren, bevor er ihn anwendet. Abgelehnte Abschnitte werden im vertauschten Format ausgegeben. Die Option -R funktioniert nicht mit ed-Diff-Skripten, da nicht genügend Informationen vorhanden sind, um die Umkehroperation zu rekonstruieren.

Wenn der erste Abschnitt eines Patches fehlschlägt, kehrt Patch den Abschnitt um, um zu sehen, ob er so angewendet werden kann. Wenn dies möglich ist, werden Sie gefragt, ob Sie die Option -R setzen möchten. Wenn dies nicht möglich ist, wird der Patch normal angewendet. (Hinweis: Diese Methode kann einen umgekehrten Patch nicht erkennen, wenn es sich um einen normalen Diff handelt und der erste Befehl ein Anhängen ist (d. h. es sollte ein Löschen sein), da Anhängen immer erfolgreich sind, da ein Null-Kontext überall übereinstimmt. Glücklicherweise fügen oder ändern die meisten Patches Zeilen hinzu oder ändern sie, sodass die meisten umgekehrten normalen Diffs mit einem Löschen beginnen, was fehlschlägt und den Heuristik-Mechanismus auslöst.)

--read-only=verhalten
Verhalten Sie sich wie gewünscht, wenn versucht wird, eine schreibgeschützte Datei zu ändern: ignorieren Sie das potenzielle Problem, warnen Sie davor (Standard) oder schlagen Sie fehl.

--reject-format=format
Erstellen Sie Ablehnungsdateien im angegebenen Format (entweder Kontext oder Unified). Ohne diese Option werden abgelehnte Abschnitte im Unified-Diff-Format ausgegeben, wenn der Eingabepatch dieses Format hat, andernfalls im normalen Kontext-Diff-Format.

-s oder --silent oder --quiet
Arbeiten Sie still, es sei denn, ein Fehler tritt auf.

--follow-symlinks
Wenn Sie nach Eingabedateien suchen, folgen Sie symbolischen Links. Ersetzen Sie die symbolischen Links, anstatt die Dateien zu ändern, auf die die symbolischen Links zeigen. Git-ähnliche Patches für symbolische Links werden nicht mehr angewendet. Diese Option existiert zur Abwärtskompatibilität mit früheren Versionen von Patch; ihre Verwendung wird nicht empfohlen.

-t oder --batch
Unterdrücken Sie Fragen wie -f, machen Sie aber einige andere Annahmen: überspringen Sie Patches, deren Header keine Dateinamen enthalten (wie bei -f); überspringen Sie Patches, für die die Datei die falsche Version für die Zeile „Prereq:“ im Patch hat; und gehen Sie davon aus, dass Patches umgekehrt sind, wenn sie so aussehen.

-T oder --set-time
Legen Sie die Änderungs- und Zugriffszeiten der gepatchten Dateien anhand der Zeitstempel in den Kontext-Diff-Headern fest. Wenn nicht anders angegeben, gehen Sie davon aus, dass die Kontext-Diff-Header die lokale Zeit verwenden.

Die Verwendung dieser Option mit Zeitstempeln, die keine Zeitzonen enthalten, wird nicht empfohlen, da Patches, die die lokale Zeit verwenden, nicht ohne Weiteres von Personen in anderen Zeitzonen verwendet werden können, und da lokale Zeitstempel bei Rückwärtsstellungen der Uhr während der Sommerzeitänderung mehrdeutig sind. Stellen Sie sicher, dass Zeitstempel Zeitzonen enthalten, oder erstellen Sie Patches mit UTC und verwenden Sie stattdessen die Option -Z oder --set-utc.

-u oder --unified
Interpretiere die Patch-Datei als einen Unified-Context-Diff.

-v oder --version
Gib den Versions-Header und die Patch-Level aus und beende das Programm.

-V Methode oder --version-control=Methode
Verwende Methode, um die Namen der Backup-Dateien zu bestimmen. Die Methode kann auch über die Umgebungsvariable PATCH_VERSION_CONTROL (oder, falls diese nicht gesetzt ist, über VERSION_CONTROL) angegeben werden, welche durch diese Option überschrieben wird. Die Methode beeinflusst nicht, ob Backup-Dateien erstellt werden; sie beeinflusst nur die Namen der erstellten Backup-Dateien.

Der Wert von Methode ähnelt der GNU Emacs Version-Control-Variable; Patch erkennt auch Synonyme, die deskriptiver sind. Die gültigen Werte für Methode sind (eindeutige Abkürzungen werden akzeptiert):

existing oder nil
Erstelle nummerierte Backups von Dateien, die bereits welche haben, andernfalls einfache Backups. Dies ist der Standard.

numbered oder t
Erstelle nummerierte Backups. Der Name der nummerierten Backup-Datei für F ist F.~N~, wobei N die Versionsnummer ist.

simple oder never
Erstelle einfache Backups. Die Optionen -B oder --prefix, -Y oder --basename-prefix und -z oder --suffix geben den Namen der einfachen Backup-Datei an. Wenn keine dieser Optionen angegeben wird, wird ein einfacher Backup-Suffix verwendet; dies ist der Wert der Umgebungsvariable SIMPLE_BACKUP_SUFFIX, falls diese gesetzt ist, andernfalls .orig.

Bei nummerierten oder einfachen Backups, wenn der Name der Backup-Datei zu lang ist, wird stattdessen der Backup-Suffix ~ verwendet; wenn selbst das Anhängen von ~ den Namen zu lang machen würde, wird ~ stattdessen an das letzte Zeichen des Dateinamens angehängt.

--verbose
Gib zusätzliche Informationen über die ausgeführte Arbeit aus.

-x num oder --debug=num
Setze interne Debugging-Flags, die nur für Patch-Programmierer von Interesse sind.

-Y Präfix oder --basename-prefix=Präfix
Verwende die einfache Methode, um die Namen der Backup-Dateien zu bestimmen (siehe die Option -V Methode oder --version-control Methode), und hänge das Präfix Präfix an den Basisnamen eines Dateinamens an, wenn der Name der Backup-Datei generiert wird. Zum Beispiel, bei -Y .del/ ist der einfache Name der Backup-Datei für src/patch/util.c src/patch/.del/util.c.

-z Suffix oder --suffix=Suffix
Verwende die einfache Methode, um die Namen der Backup-Dateien zu bestimmen (siehe die Option -V Methode oder --version-control Methode), und verwende Suffix als Suffix. Zum Beispiel, bei -z - ist der Name der Backup-Datei für src/patch/util.c src/patch/util.c-.

-Z oder --set-utc
Setze die Änderungs- und Zugriffszeiten der gepatchten Dateien anhand der in den Context-Diff-Headern angegebenen Zeitstempel. Wenn in den Zeitstempeln nicht anders angegeben, gehe davon aus, dass die Context-Diff-Header die koordinierte Weltzeit (UTC, oft als GMT bekannt) verwenden. Siehe auch die Option -T oder --set-time.

Die Optionen -Z oder --set-utc und -T oder --set-time ändern normalerweise nicht die Zeit einer Datei, wenn die ursprüngliche Zeit der Datei nicht mit der in dem Patch-Header angegebenen Zeit übereinstimmt oder wenn der Inhalt nicht genau mit dem Patch übereinstimmt. Wenn jedoch die Option -f oder --force angegeben wird, wird die Dateizeit unabhängig davon gesetzt.

Aufgrund der Einschränkungen des Diff-Ausgabeformats können diese Optionen die Zeitstempel von Dateien nicht aktualisieren, deren Inhalt sich nicht geändert hat. Wenn Sie diese Optionen verwenden, sollten Sie außerdem alle Dateien entfernen (z. B. mit make clean), die von den gepatchten Dateien abhängen, damit spätere Aufrufe von make nicht durch die Zeitstempel der gepatchten Dateien verwirrt werden.

UMGEBUNG

^ ATCH_GET Gibt an, ob patch standardmäßig fehlende oder schreibgeschützte Dateien aus RCS, ClearCase, Perforce oder SCCS bezieht; siehe die Option -g oder --get.

^ OSIXLY_CORRECT Wenn diese Variable gesetzt ist, entspricht patch standardmäßig strikter dem POSIX-Standard; siehe die Option --posix.

^ UOTING_STYLE Standardwert für die Option --quoting-style.

^ IMPLE_BACKUP_SUFFIX Erweiterung, die für einfache Backup-Dateinamen anstelle von .orig verwendet wird.

^ MPDIR, TMP, TEMP Verzeichnis, in dem temporäre Dateien gespeichert werden; patch verwendet die erste Umgebungsvariable in dieser Liste, die gesetzt ist. Wenn keine gesetzt ist, ist der Standardwert systemabhängig; normalerweise ist dies /tmp unter Unix-Systemen.

^ ERSION_CONTROL oder PATCH_VERSION_CONTROL Wählt den Stil der Versionskontrolle aus; siehe die Option -v oder --version-control.

DATEIEN

^ TMPDIR/p* temporäre Dateien

^ dev/tty kontrollierendes Terminal; wird verwendet, um Antworten auf Fragen zu erhalten, die dem Benutzer gestellt werden.

SIEHE AUCH

diff(1), ed(1), merge(1).

Marshall T. Rose und Einar A. Stefferud, Proposed Standard for Message Encapsulation, Internet RFC 934 [https://datatracker.ietf.org/doc/html/rfc934] (1985-01).

HINWEISE FÜR PATCH-VERSENDER

Es gibt einige Dinge, die Sie beachten sollten, wenn Sie Patches versenden.

Erstellen Sie Ihre Patches systematisch. Wenn Sie ein Versionskontrollsystem verwenden, sollte dies einfach sein; zum Beispiel können Sie mit Git git diff verwenden. Andernfalls ist eine gute Methode der Befehl diff -Naur old new, wobei old und new die alten und neuen Verzeichnisse identifizieren. Die Namen old und new sollten keine Schrägstriche enthalten.

Wenn der Patch sowohl Datei-Zeitstempel als auch Datei-Inhalte kommunizieren soll, sollten die Header der Diff-Befehle Datums- und Zeitangaben in universeller Zeit im traditionellen Unix-Format enthalten, damit die Empfänger der Patches die Option -Z oder --set-utc verwenden können. Hier ist ein Beispielbefehl, um solche Header mit Bourne-Shell-Syntax zu generieren:

LC_ALL=C TZ=UTC0 diff -Naur myprog-2.7 myprog-2.8

Teilen Sie Ihren Empfängern mit, wie sie den Patch anwenden können, indem Sie ihnen sagen, in welches Verzeichnis sie wechseln und welche Patch-Optionen sie verwenden sollen. Die Option -Np1 wird empfohlen. Testen Sie das Verfahren, indem Sie so tun, als wären Sie ein Empfänger, und wenden Sie Ihren Patch auf eine Kopie der Originaldateien an.

Sie können den Benutzern viel Ärger ersparen, indem Sie eine Datei patchlevel.h erstellen, die gepatcht wird, um die Patch-Version als erste Diff in der von Ihnen versendeten Patch-Datei zu erhöhen. Wenn Sie eine Zeile Prereq: einfügen, verhindert dies, dass sie Patches in der falschen Reihenfolge anwenden, ohne eine Warnung.

Sie können eine Datei erstellen, indem Sie einen Diff senden, der /dev/null oder eine leere Datei, die auf den Beginn der Epoche (1970-01-01 00:00:00 UTC) datiert ist, mit der Datei vergleicht, die Sie erstellen möchten. Dies funktioniert nur, wenn die Datei, die Sie erstellen möchten, noch nicht im Zielverzeichnis vorhanden ist. Umgekehrt können Sie eine Datei entfernen, indem Sie einen Kontext-Diff senden, der die zu löschende Datei mit einer leeren Datei vergleicht, die auf den Beginn der Epoche datiert ist. Die Datei wird entfernt, es sei denn, patch entspricht dem POSIX-Standard und die Option -E oder --remove-empty-files wird nicht angegeben. Eine einfache Möglichkeit, Patches zu generieren, die Dateien erstellen und entfernen, ist die Verwendung der Option -N oder --new-file von GNU diff.

Wenn der Empfänger die Option -pN verwenden soll, senden Sie keine Ausgabe, die wie folgt aussieht:

diff -Naur v2.0.29/prog/README prog/README
--- v2.0.29/prog/README   Mon Mar 10 15:13:12 2024
+++ prog/README   Mon Mar 17 14:58:22 2024

da die beiden Dateinamen eine unterschiedliche Anzahl von Schrägstrichen aufweisen, und verschiedene Versionen von patch die Dateinamen unterschiedlich interpretieren. Um Verwirrung zu vermeiden, senden Sie stattdessen eine Ausgabe, die wie folgt aussieht:

diff -Naur v2.0.29/prog/README v2.0.30/prog/README
--- v2.0.29/prog/README   Mon Mar 10 15:13:12 2024
+++ v2.0.30/prog/README   Mon Mar 17 14:58:22 2024

Vermeiden Sie das Senden von Patches, die Backup-Dateinamen wie README.orig vergleichen, da dies patch dazu verleiten könnte, eine Backup-Datei anstelle der eigentlichen Datei zu patchen. Senden Sie stattdessen Patches, die dieselben Basisdateinamen in verschiedenen Verzeichnissen vergleichen, z. B. old/README und new/README.

Achten Sie darauf, keine umgekehrten Patches zu senden, da dies die Leute verwirren könnte und sie sich fragen, ob sie das Patch bereits angewendet haben.

Versuchen Sie, keine Patches zu senden, die abgeleitete Dateien ändern (z. B. die Datei configure, in der sich eine Zeile befindet, die in Ihrer Makefile lautet: configure: configure.ac), da der Empfänger die abgeleiteten Dateien sowieso neu generieren können sollte. Wenn Sie unbedingt Diffs von abgeleiteten Dateien senden müssen, generieren Sie die Diffs mit UTC, lassen Sie die Empfänger das Patch mit der Option -Z oder --set-utc anwenden und lassen Sie sie alle nicht gepatchten Dateien entfernen, die von gepatchten Dateien abhängen (z. B. mit make clean).

Auch wenn Sie es vielleicht schaffen, 582 Diff-Einträge in eine Datei zu packen, ist es möglicherweise sinnvoller, verwandte Patches in separate Dateien zu gruppieren, falls etwas schiefgeht.

DIAGNOSTIK

Diagnostik zeigen in der Regel an, dass patch Ihre Patch-Datei nicht parsen konnte.

Wenn die Option --verbose angegeben ist, bedeutet die Meldung Hmm..., dass es nicht verarbeiteten Text in der Patch-Datei gibt und dass patch versucht, zu erkennen, ob es sich dabei um ein Patch handelt und, falls ja, um welche Art von Patch es sich handelt.

Der Exit-Status von patch ist 0, wenn alle Hunks erfolgreich angewendet wurden, 1, wenn einige Hunks nicht angewendet werden konnten oder es Merge-Konflikte gab, und 2, wenn es ein schwerwiegenderes Problem gibt. Wenn Sie eine Reihe von Patches in einer Schleife anwenden, sollten Sie diesen Exit-Status überprüfen, damit Sie nicht ein späteres Patch auf eine teilweise gepatchte Datei anwenden.

EINSCHRÄNKUNGEN

Kontext-Diffs können die Erstellung oder Löschung leerer Dateien, leerer Verzeichnisse oder spezieller Dateien wie symbolischer Links nicht zuverlässig darstellen. Sie können auch keine Änderungen an Dateimetadaten darstellen, wie z. B. Eigentumsverhältnisse, Berechtigungen oder ob eine Datei ein Hardlink zu einer anderen Datei ist. Wenn auch solche Änderungen erforderlich sind, sollten separate Anweisungen (z. B. ein Shell-Skript), um diese durchzuführen, dem Patch beiliegen.

Das Patch-Programm kann nicht erkennen, ob die Zeilennummern in einem Ed-Skript falsch sind, und kann schlechte Zeilennummern in einem normalen Diff nur dann erkennen, wenn es eine Änderung oder Löschung findet. Ein Kontext-Diff mit einem Fuzzy-Faktor von 3 kann das gleiche Problem haben. In diesen Fällen sollten Sie wahrscheinlich ein Kontext-Diff durchführen, um zu sehen, ob die Änderungen sinnvoll waren. Natürlich ist das fehlerfreie Kompilieren ein ziemlich guter Indikator dafür, dass das Patch erfolgreich war, aber nicht immer.

Das Patch-Programm erzeugt normalerweise die richtigen Ergebnisse, selbst wenn es viel raten muss. Die Ergebnisse sind jedoch nur dann garantiert korrekt, wenn das Patch auf genau die gleiche Version der Datei angewendet wird, von der das Patch erstellt wurde.

KOMPATIBILITÄTSPROBLEME

Der POSIX-Standard spezifiziert ein Verhalten, das sich von GNU Patch unterscheidet.

In POSIX Patch werden bei nicht verwendeter Option -b keine Backups erstellt, selbst wenn es eine Abweichung gibt. In GNU Patch ist dieses Verhalten mit der Option --no-backup-if-mismatch oder durch Konformität mit POSIX mit der Option --posix oder durch Setzen der Umgebungsvariablen POSIXLY_CORRECT aktiviert.

Wenn das Patch-Programm den Namen der zu patchenden Datei aus dem Patch-Header ableitet, verwendet es eine komplizierte Methode, die optional POSIX-konform ist. Die Methode ist äquivalent zu POSIX, wenn die Dateinamen im Kontext-Diff-Header und in der Zeile Index: alle identisch sind, nachdem die Präfixe entfernt wurden. Ihr Patch ist normalerweise kompatibel, wenn die Dateinamen in jedem Header die gleiche Anzahl von Schrägstrichen enthalten.

Beschränken Sie sich auf die folgenden Optionen, wenn Sie Anweisungen senden, die von jedem Benutzer von GNU Patch oder einem Patch, das mit POSIX kompatibel ist, ausgeführt werden sollen. Leerzeichen sind in der folgenden Liste optional.

-b
-c
-d dir
-D define
-e
-i patchfile
-l
-n
-N
-o outfile
-p num
-R
-r rejectfile
-u

FEHLER

Bitte melden Sie Fehler per E-Mail an <_>.

Wenn Code dupliziert wurde (z. B. mit #ifdef OLDCODE ... #else ... #endif), ist das Patch-Programm nicht in der Lage, beide Versionen zu patchen, und wenn es überhaupt funktioniert, wird es wahrscheinlich die falsche Version patchen und Ihnen mitteilen, dass es erfolgreich war.

Wenn Sie ein Patch anwenden, das Sie bereits angewendet haben, hält das Patch-Programm es für ein umgekehrtes Patch und bietet an, das Patch rückgängig zu machen. Dies könnte man als eine Funktion betrachten.

Die Berechnung, wie ein Hunk zusammengeführt werden soll, ist deutlich schwieriger als die Verwendung des Standard-Fuzzy-Algorithmus. Größere Hunks, mehr Kontext, eine größere Abweichung vom ursprünglichen Speicherort und eine schlechtere Übereinstimmung verlangsamen alle den Algorithmus.

LIZENZ

Copyright © 1989–2025 Free Software Foundation, Inc. Copyright © 1984–1986, 1988 Larry Wall.

Es wird die Erlaubnis erteilt, wortgetreue Kopien dieses Handbuchs zu erstellen und zu verteilen, vorausgesetzt, der Urheberrechtsvermerk und dieser Erlaubnisvermerk bleiben auf allen Kopien erhalten.

Es wird die Erlaubnis erteilt, modifizierte Versionen dieses Handbuchs zu kopieren und zu verteilen, unter den Bedingungen für die wortgetreue Vervielfältigung, vorausgesetzt, dass das gesamte resultierende abgeleitete Werk unter den Bedingungen einer identischen Genehmigungserklärung verteilt wird.

Es wird die Erlaubnis erteilt, Übersetzungen dieses Handbuchs in eine andere Sprache zu kopieren und zu verteilen, unter den oben genannten Bedingungen für modifizierte Versionen, mit der Ausnahme, dass diese Genehmigungserklärung in Übersetzungen, die von den Urheberrechtsinhabern genehmigt wurden, anstelle der Originalversion auf Englisch enthalten sein kann.

AUTOREN

Larry Wall schrieb die ursprüngliche Version von patch. Paul Eggert entfernte die willkürlichen Beschränkungen von patch; fügte Unterstützung für Binärdateien, das Setzen von Datei-Zeitstempeln und das Löschen von Dateien hinzu; und sorgte dafür, dass es besser mit POSIX übereinstimmt. Andere Mitwirkende sind Wayne Davison, der die Unterstützung für unidiff hinzufügte, und David MacKenzie, der die Unterstützung für Konfiguration und Backup hinzufügte. Andreas Gruenbacher fügte die Unterstützung für das Zusammenführen hinzu.