patch(1)

NAMN

patch – applicera en diff-fil på ett original

SYNOPSIS

patch [options] [originalfile [patchfile]]

men vanligen bara

patch -pnum <patchfile

BESKRIVNING

patch tar en patchfil patchfile som innehåller en differenslista producerad av programmet diff och applicerar dessa skillnader på en eller flera originalfiler, vilket producerar patchade versioner. Normalt läggs de patchade versionerna i originalens ställe. Säkerhetskopior kan skapas; se optionen -b eller --backup. Namnen på filerna som ska patchas tas vanligen från patchfilen, men om det bara finns en fil som ska patchas kan den anges på kommandoraden som originalfile.

Vid start försöker patch bestämma typen av diff-listan, om detta inte åsidosätts av optionen -c (--context), -e (--ed), -n (--normal) eller -u (--unified). Kontext-diffar, gammal stil, ny stil och unified, samt normala diffar appliceras av programmet patch självt, medan ed-diffar helt enkelt matas till editorn ed(1) via en pipe.

patch försöker hoppa över allt inledande skräp, applicera diffen och sedan hoppa över allt avslutande skräp. Därför kan du mata ett e-postmeddelande som innehåller en diff-lista till patch, och det bör fungera. Om hela diffen är indragen med ett konsekvent antal tecken, om rader slutar med CRLF, eller om en diff är inkapslad en eller flera gånger genom att lägga till "- " framför rader som börjar med "-" enligt Internet RFC 934, tas detta hänsyn till. Efter att indragning eller inkapsling tagits bort ignoreras rader som börjar med #, eftersom de betraktas som kommentarer.

Med kontext-diffar, och i mindre grad med normala diffar, kan patch upptäcka när radnumren som nämns i patchen är felaktiga och försöker hitta rätt plats att applicera varje hunk i patchen. Som första gissning tar den radnumret som nämns för hunken, plus eller minus eventuell offset som använts vid applicering av föregående hunk. Om det inte är rätt plats söker patch både framåt och bakåt efter en uppsättning rader som matchar kontexten som anges i hunken. Först letar patch efter en plats där alla kontextrader matchar. Om ingen sådan plats hittas, och det är en kontext-diff, och den maximala fuzz-faktorn är satt till 1 eller mer, görs en ny sökning där första och sista kontextraden ignoreras. Om det misslyckas, och den maximala fuzz-faktorn är satt till 2 eller mer, ignoreras de första två och sista två kontextraderna och en ny sökning görs. Standardvärdet för maximal fuzz-faktor är 2.

Hunkar med mindre prefixkontext än suffixkontext, efter applicering av fuzz, måste appliceras i början av filen om deras första radnummer är 1. Hunkar med mer prefixkontext än suffixkontext, efter applicering av fuzz, måste appliceras i slutet av filen.

Om patch inte kan hitta en plats att installera den hunken av patchen, lägger den hunken i en reject-fil, som normalt är namnet på utdatafilen plus suffixet .rej, eller # om .rej skulle skapa ett filnamn som är för långt. Om till och med att lägga till det enskilda tecknet # gör filnamnet för långt ersätter # filnamnets sista tecken.

Den avvisade hunken skrivs ut i unified- eller context-diff-format. Om indatan var en normal diff är många av kontexterna helt enkelt null. Radnumren för hunkarna i reject-filen kan skilja sig från dem i patchfilen: de återspeglar den ungefärliga plats där patch tror att de misslyckade hunkarna hör hemma i den nya filen snarare än i den gamla.

När varje hunk är klar får du veta om hunken misslyckades, och i så fall på vilken rad, i den nya filen, patch trodde att hunken skulle placeras. Om hunken installeras på en annan rad än radnumret som anges i diffen får du veta offseten. En enda stor offset kan indikera att en hunk installerades på fel plats. Du får också veta om en fuzz-faktor användes för att skapa matchningen, i vilket fall du också bör vara något misstänksam. Om optionen --verbose anges får du också veta om hunkar som matchar exakt.

Om ingen originalfil origfile anges på kommandoraden försöker patch räkna ut från det inledande skräpet vad namnet på filen som ska redigeras är, enligt följande regler.

Först tar patch en ordnad lista över kandidatfilnamn enligt följande:

• Om huvudet är ett huvud för en kontext-diff tar patch de gamla och nya filnamnen i huvudet. Ett namn ignoreras om det inte har tillräckligt många snedstreck för att uppfylla optionen -p num eller --strip= num. Namnet /dev/null ignoreras också.

• Om det finns en Index:-rad i det inledande skräpet och om antingen de gamla och nya namnen båda saknas eller om patch följer POSIX, tar patch namnet i Index:-raden.

• För syftet med följande regler betraktas kandidatfilnamnen i ordningen gammal, ny, index, oavsett ordningen de förekommer i huvudet.

Sedan väljer patch ett filnamn från kandidatlistan enligt följande:

• Om några av de namngivna filerna finns väljer patch det första namnet om det följer POSIX, och annars det bästa namnet.

• Om patch inte ignorerar RCS, ClearCase, Perforce och SCCS, se optionen -g num eller --get= num, och inga namngivna filer finns men en RCS-, ClearCase-, Perforce- eller SCCS-master hittas, väljer patch den första namngivna filen med en RCS-, ClearCase-, Perforce- eller SCCS-master.

• Om inga namngivna filer finns, ingen RCS-, ClearCase-, Perforce- eller SCCS-master hittades, några namn anges, patch inte följer POSIX, och patchen verkar skapa en fil, väljer patch det bästa namnet som kräver skapande av minst antal kataloger.

• Om inget filnamn resulterar från ovanstående heuristik ombeds du ange namnet på filen som ska patchas, och patch väljer det namnet.

För att bestämma det bästa av en icke-tom lista med filnamn tar patch först alla namn med minst antal sökvägskomponenter; av dessa tar den sedan alla namn med kortast basnamn; av dessa tar den sedan alla kortaste namn; slutligen tar den det första återstående namnet.

Dessutom, om det inledande skräpet innehåller en Prereq:-rad, tar patch det första ordet från förutsättningsraden, normalt ett versionsnummer, och kontrollerar originalfilen för att se om det ordet kan hittas. Om inte ber patch om bekräftelse innan den fortsätter.

Resultatet av allt detta är att du bör kunna köra något som följande shellkommando:

patch -d /usr/src/local/blurfl

och patcha en fil i katalogen blurfl direkt från en patch som läses från standardindata.

Om patchfilen innehåller mer än en patch försöker patch applicera var och en av dem som om de kom från separata patchfiler. Detta betyder bland annat att det antas att namnet på filen som ska patchas måste bestämmas för varje diff-lista, och att skräpet före varje diff-lista innehåller intressanta saker som filnamn och revisionsnivå, som nämnts tidigare.

OPTIONER

-b eller --backup

Skapa säkerhetskopior. Det vill säga, vid patchning av en fil, byt namn på eller kopiera originalet i stället för att ta bort det. Se optionen -V eller --version-control för detaljer om hur säkerhetskopiefilnamn bestäms.

--backup-if-mismatch

Säkerhetskopiera en fil om patchen inte matchar filen exakt och om säkerhetskopior inte annars begärs. Detta är standard om inte patch följer POSIX.

--no-backup-if-mismatch

Säkerhetskopiera inte en fil om patchen inte matchar filen exakt och om säkerhetskopior inte annars begärs. Detta är standard om patch följer POSIX.

-B pref eller --prefix= pref

Använd metoden simple för att bestämma säkerhetskopiefilnamn, se optionen -V method eller --version-control method, och lägg till pref till ett filnamn när dess säkerhetskopiefilnamn genereras. Till exempel, med -B /junk/ är det enkla säkerhetskopiefilnamnet för src/patch/util.c /junk/src/patch/util.c.

--binary

Skriv alla filer i binärt läge, förutom standardutdata och /dev/tty. Vid läsning, inaktivera heuristiken för att omvandla CRLF-radslut till LF-radslut. Denna option behövs på POSIX-system när patchar som genererats på icke-POSIX-system appliceras på icke-POSIX-filer. På POSIX-system omvandlar filläsningar och filskrivningar aldrig radslut. På Windows omvandlar läsningar och skrivningar radslut som standard, och patchar bör genereras med diff --binary när radslut är betydelsefulla.

-c eller --context

Tolka patchfilen som en vanlig kontext-diff.

-d dir eller --directory= dir

Byt till katalogen dir omedelbart, innan något annat görs.

-D define eller --ifdef= define

Använd konstruktionen #ifdef ... #endif för att markera ändringar, med define som den särskiljande symbolen.

--dry-run

Skriv ut resultatet av att applicera patcharna utan att faktiskt ändra några filer.

-e eller --ed

Tolka patchfilen som ett ed-skript.

-E eller --remove-empty-files

Ta bort utdatafiler som är tomma efter att patcharna har applicerats. Normalt är denna option onödig, eftersom patch kan undersöka tidsstämplarna i huvudet för att avgöra om en fil ska finnas efter patchning. Om indatan inte är en kontext-diff eller om patch följer POSIX, tar patch dock inte bort tomma patchade filer om inte denna option anges. När patch tar bort en fil försöker den också ta bort eventuella tomma överordnade kataloger.

-f eller --force

Anta att användaren vet exakt vad han eller hon gör, och ställ inga frågor. Hoppa över patchar vars huvuden inte säger vilken fil som ska patchas; patcha filer även om de har fel version för Prereq:-raden i patchen; och anta att patchar inte är omvända även om de ser ut som om de är det. Denna option undertrycker inte kommentarer; använd -s för det.

-F num eller --fuzz= num

Sätt den maximala fuzz-faktorn. Denna option gäller bara diffar som har kontext, och gör att patch ignorerar upp till så många kontextrader vid sökning efter platser att installera en hunk. Observera att en större fuzz-faktor ökar sannolikheten för en felaktig patch. Standard-fuzz-faktorn är 2. En fuzz-faktor större än eller lika med antalet kontextrader i kontext-diffen, vanligen 3, ignorerar all kontext.

-g num eller --get= num

Denna option styr patchs åtgärder när en fil är under RCS- eller SCCS-kontroll och inte finns eller är skrivskyddad och matchar standardversionen, eller när en fil är under ClearCase- eller Perforce-kontroll och inte finns. Om num är positivt hämtar, eller checkar ut, patch filen från versionshanteringssystemet; om noll ignorerar patch RCS, ClearCase, Perforce och SCCS och hämtar inte filen; och om negativt frågar patch användaren om filen ska hämtas. Standardvärdet för denna option ges av värdet på miljövariabeln PATCH_GET om den är satt; om inte är standardvärdet noll.

--help

Skriv ut en sammanfattning av optioner och avsluta.

-i patchfile eller --input= patchfile

Läs patchen från patchfile. Om patchfile är -, läs från standardindata, standardvärdet.

-l eller --ignore-whitespace

Matcha mönster löst, om tabbar eller blanksteg har förvanskats i dina filer. Varje sekvens av ett eller flera blanktecken i patchfilen matchar valfri sekvens i originalfilen, och sekvenser av blanktecken vid radslut ignoreras. Normala tecken måste fortfarande matcha exakt. Varje kontextrad måste fortfarande matcha en rad i originalfilen.

--merge eller --merge=merge eller --merge=diff3

Slå samman en patchfil med originalfilerna liknande diff3(1) eller merge(1). Om en konflikt hittas skriver patch ut en varning och omger konflikten med raderna <<<<<<< och >>>>>>>. En typisk konflikt ser ut så här:

<<<<<<<
lines from the original file
|||||||
original lines from the patch
=======
new lines from the patch
>>>>>>>

Det valfria argumentet till --merge bestämmer utdataformatet för konflikter: diff3-formatet visar sektionen ||||||| med originalraderna från patchen; i merge-formatet saknas denna sektion. Merge-formatet är standard.

Denna option implicerar --forward och tar inte hänsyn till optionen --fuzz= num.

-n eller --normal

Tolka patchfilen som en normal diff.

-N eller --forward

När en patch inte går att applicera kontrollerar patch vanligen om patchen ser ut att redan ha applicerats genom att försöka omvänd-applicera den första hunken. Option --forward förhindrar detta. Se även -R.

-o outfile eller --output= outfile

Skicka utdata till outfile i stället för att patcha filer på plats. Använd inte denna option om outfile är en av filerna som ska patchas. När outfile är -, skicka utdata till standardutdata och skicka alla meddelanden som vanligtvis skulle gå till standardutdata till standardfel.

-p num eller --strip= num

Ta bort det minsta prefixet som innehåller num inledande snedstreck från varje filnamn som hittas i patchfilen. En sekvens av ett eller flera intilliggande snedstreck räknas som ett enda snedstreck. Detta styr hur filnamn som hittas i patchfilen behandlas, om du håller dina filer i en annan katalog än personen som skickade ut patchen. Anta till exempel att filnamnet i patchfilen var:

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

att sätta -p0 ger hela filnamnet oförändrat, -p1 ger:

u/howard/src/blurfl/blurfl.c

utan det inledande snedstrecket, -p4 ger:

blurfl/blurfl.c

och att inte ange -p alls ger bara blurfl.c. Vad du än får fram letas efter antingen i den aktuella katalogen eller i katalogen som anges med optionen -d.

--posix

Följ POSIX-standarden striktare, enligt följande.

• Ta den första befintliga filen från listan gammal, ny, index när filnamn härleds från diff-huvuden.
• Ta inte bort filer som är tomma efter patchning.
• Fråga inte om filer ska hämtas från RCS, ClearCase, Perforce eller SCCS.
• Kräv att alla optioner föregår filerna på kommandoraden.
• Säkerhetskopiera inte filer när det finns en missmatchning.

--quoting-style= word

Använd stilen word för att citera utdatanamn. word ska vara ett av följande:

literal

Skriv ut namn som de är.

shell

Citera namn för skalet om de innehåller skalmetatecken eller skulle orsaka tvetydig utdata.

shell-always

Citera namn för skalet även om de normalt inte skulle kräva citering.

c

Citera namn som för en C-språksträng.

escape

Citera som med c förutom att utelämna de omgivande dubbla citattecknen.

Du kan ange standardvärdet för optionen --quoting-style med miljövariabeln QUOTING_STYLE. Om den miljövariabeln inte är satt är standardvärdet shell.

-r rejectfile eller --reject-file= rejectfile

Lägg rejects i rejectfile i stället för standardfilen .rej. När rejectfile är -, kasta rejects.

-R eller --reverse

Anta att denna patch skapades med de gamla och nya filerna omkastade. Ja, jag är rädd att det händer ibland, mänsklig natur som den är. patch försöker byta riktning på varje hunk innan den appliceras. Rejects skrivs ut i det omkastade formatet. Option -R fungerar inte med ed-diffskript eftersom det finns för lite information för att rekonstruera den omvända operationen.

Om den första hunken i en patch misslyckas vänder patch hunken för att se om den kan appliceras på det sättet. Om den kan det får du frågan om du vill att optionen -R ska sättas. Om den inte kan det fortsätter patchen att appliceras normalt. Observera: denna metod kan inte upptäcka en omvänd patch om den är en normal diff och om det första kommandot är en append, det vill säga det borde ha varit en delete, eftersom append alltid lyckas på grund av att en null-kontext matchar var som helst. Lyckligtvis lägger de flesta patchar till eller ändrar rader snarare än tar bort dem, så de flesta omvända normala diffar börjar med en delete, som misslyckas och utlöser heuristiken.

--read-only= behavior

Bete dig som begärt när en skrivskyddad fil ska ändras: ignore problemet, warn om det, standard, eller fail.

--reject-format= format

Skapa reject-filer i angivet format, antingen context eller unified. Utan denna option skrivs avvisade hunkar ut i unified diff-format om indatapatchen hade det formatet, annars i vanligt context diff-format.

-s eller --silent eller --quiet

Arbeta tyst, om inget fel inträffar.

--follow-symlinks

Följ symboliska länkar när indatafiler söks. Ersätter de symboliska länkarna, i stället för att ändra filerna som de symboliska länkarna pekar på. Git-stilpatchar till symboliska länkar kommer inte längre att kunna appliceras. Denna option finns för bakåtkompatibilitet med tidigare versioner av patch; dess användning avråds.

-t eller --batch

Undertryck frågor likt -f, men gör några andra antaganden: hoppa över patchar vars huvuden inte innehåller filnamn, samma som -f; hoppa över patchar för vilka filen har fel version för Prereq:-raden i patchen; och anta att patchar är omvända om de ser ut som om de är det.

-T eller --set-time

Sätt ändrings- och åtkomsttider för patchade filer från tidsstämplar som anges i context diff-huvuden. Om inte annat anges i tidsstämplarna, anta att context diff-huvudena använder lokal tid.

Användning av denna option med tidsstämplar som inte inkluderar tidszoner rekommenderas inte, eftersom patchar som använder lokal tid inte lätt kan användas av personer i andra tidszoner, och eftersom lokala tidsstämplar är tvetydiga när lokala klockor flyttas bakåt under justeringar för sommartid. Se till att tidsstämplar inkluderar tidszoner, eller generera patchar med UTC och använd optionen -Z eller --set-utc i stället.

-u eller --unified

Tolka patchfilen som en unified context diff.

-v eller --version

Skriv ut patchs revisionshuvud och patchnivå, och avsluta.

-V method eller --version-control= method

Använd method för att bestämma säkerhetskopiefilnamn. Metoden kan också anges av miljövariabeln PATCH_VERSION_CONTROL, eller, om den inte är satt, VERSION_CONTROL, som åsidosätts av denna option. Metoden påverkar inte om säkerhetskopior görs; den påverkar bara namnen på eventuella säkerhetskopior som görs.

Värdet på method är som GNU Emacs version-control-variabel; patch känner också igen synonymer som är mer beskrivande. De giltiga värdena för method är, unika förkortningar accepteras:

existing eller nil

Skapa numrerade säkerhetskopior av filer som redan har sådana, annars enkla säkerhetskopior. Detta är standard.

numbered eller t

Skapa numrerade säkerhetskopior. Det numrerade säkerhetskopiefilnamnet för F är F .~ N ~ där N är versionsnumret.

simple eller never

Skapa enkla säkerhetskopior. Optionerna -B eller --prefix, -Y eller --basename-prefix, och -z eller --suffix anger det enkla säkerhetskopiefilnamnet. Om ingen av dessa optioner anges används ett enkelt säkerhetskopiesuffix; det är värdet på miljövariabeln SIMPLE_BACKUP_SUFFIX om den är satt, och annars .orig.

Med numrerade eller enkla säkerhetskopior används säkerhetskopiesuffixet ~ om säkerhetskopiefilnamnet är för långt; om till och med att lägga till ~ skulle göra namnet för långt ersätter ~ filnamnets sista tecken.

--verbose

Skriv ut extra information om arbetet som utförs.

-x num eller --debug= num

Sätt interna felsökningsflaggor av intresse endast för patch-patchare.

-Y pref eller --basename-prefix= pref

Använd metoden simple för att bestämma säkerhetskopiefilnamn, se optionen -V method eller --version-control method, och prefixa pref till basnamnet för ett filnamn när dess säkerhetskopiefilnamn genereras. Till exempel, med -Y .del/ är det enkla säkerhetskopiefilnamnet för src/patch/util.c src/patch/.del/util.c.

-z suffix eller --suffix= suffix

Använd metoden simple för att bestämma säkerhetskopiefilnamn, se optionen -V method eller --version-control method, och använd suffix som suffix. Till exempel, med -z - är säkerhetskopiefilnamnet för src/patch/util.c src/patch/util.c-.

-Z eller --set-utc

Sätt ändrings- och åtkomsttider för patchade filer från tidsstämplar som anges i context diff-huvuden. Om inte annat anges i tidsstämplarna, anta att context diff-huvudena använder Coordinated Universal Time, UTC, ofta känt som GMT. Se också optionen -T eller --set-time.

Optionerna -Z eller --set-utc och -T eller --set-time avstår normalt från att sätta en fils tid om filens ursprungliga tid inte matchar tiden som anges i patchhuvudet, eller om dess innehåll inte matchar patchen exakt. Om optionen -f eller --force anges sätts dock filtiden oavsett.

På grund av begränsningarna i diff-utdataformatet kan dessa optioner inte uppdatera tiderna för filer vars innehåll inte har ändrats. Om du använder dessa optioner bör du dessutom ta bort, t.ex. med make clean, alla filer som beror på de patchade filerna, så att senare körningar av make inte förvirras av de patchade filernas tider.

MILJÖ

PATCH_GET

Detta anger om patch som standard hämtar saknade eller skrivskyddade filer från RCS, ClearCase, Perforce eller SCCS; se optionen -g eller --get.

POSIXLY_CORRECT

Om satt följer patch POSIX-standarden striktare som standard: se optionen --posix.

QUOTING_STYLE

Standardvärde för optionen --quoting-style.

SIMPLE_BACKUP_SUFFIX

Ändelse att använda för enkla säkerhetskopiefilnamn i stället för .orig.

TMPDIR, TMP, TEMP

Katalog där temporära filer ska placeras; patch använder den första miljövariabeln i denna lista som är satt. Om ingen är satt är standardvärdet systemberoende; det är normalt /tmp på Unix-värdar.

VERSION_CONTROL eller PATCH_VERSION_CONTROL

Väljer version-control-stil; se optionen -v eller --version-control.

FILER

$TMPDIR/p*

temporära filer

/dev/tty

styrande terminal; används för att få svar på frågor som ställs till användaren

SE ÄVEN

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

Marshall T. Rose och Einar A. Stefferud, Proposed Standard for Message Encapsulation, Internet RFC 934:

https://datatracker.ietf.org/doc/html/rfc934

1985-01.

ANMÄRKNINGAR FÖR PATCH-SÄNDARE

Det finns flera saker du bör ha i åtanke om du ska skicka ut patchar.

Skapa din patch systematiskt. När du använder ett versionshanteringssystem bör detta vara enkelt; med Git kan du till exempel använda git diff. Annars är en bra metod kommandot diff -Naur old new där old och new identifierar de gamla och nya katalogerna. Namnen old och new bör inte innehålla några snedstreck.

Om patchen ska kommunicera filtidsstämplar såväl som filinnehåll bör dess diff-kommandons huvuden ha datum och tider i Universal Time med traditionellt Unix-format, så att patchmottagare kan använda optionen -Z eller --set-utc. Här är ett exempelkommando för att generera sådana huvuden, med Bourne shell-syntax:

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

Tala om för dina mottagare hur patchen ska appliceras genom att tala om vilken katalog de ska cd till och vilka patch-optioner som ska användas. Optionssträngen -Np1 rekommenderas. Testa din procedur genom att låtsas vara en mottagare och applicera din patch på en kopia av originalfilerna.

Du kan spara människor mycket bekymmer genom att hålla en patchlevel.h-fil som patchas för att öka patchnivån som första diff i patchfilen du skickar ut. Om du lägger in en Prereq:-rad med patchen låter den dem inte applicera patchar i fel ordning utan någon varning.

Du kan skapa en fil genom att skicka ut en diff som jämför /dev/null eller en tom fil daterad epoken, 1970-01-01 00:00:00 UTC, med filen du vill skapa. Detta fungerar bara om filen du vill skapa inte redan finns i målkatalogen. Omvänt kan du ta bort en fil genom att skicka ut en context-diff som jämför filen som ska tas bort med en tom fil daterad epoken. Filen tas bort om inte patch följer POSIX och optionen -E eller --remove-empty-files inte anges. Ett enkelt sätt att generera patchar som skapar och tar bort filer är att använda GNU diffs option -N eller --new-file.

Om mottagaren ska använda optionen -p N, skicka inte utdata som ser ut så här:

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

eftersom de två filnamnen har olika antal snedstreck, och olika versioner av patch tolkar filnamnen olika. För att undvika förvirring, skicka utdata som ser ut så här i stället:

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

Undvik att skicka patchar som jämför säkerhetskopiefilnamn som README.orig, eftersom detta kan förvirra patch till att patcha en säkerhetskopia i stället för den riktiga filen. Skicka i stället patchar som jämför samma basfilnamn i olika kataloger, t.ex. old/README och new/README.

Var noga med att inte skicka ut omvända patchar, eftersom det får människor att undra om de redan har applicerat patchen.

Försök att inte låta din patch ändra härledda filer, t.ex. filen configure där det finns en rad configure: configure.ac i din makefile, eftersom mottagaren ändå bör kunna regenerera de härledda filerna. Om du måste skicka diffar av härledda filer, generera diffarna med UTC, låt mottagarna applicera patchen med optionen -Z eller --set-utc, och låt dem ta bort alla opatchade filer som beror på patchade filer, t.ex. med make clean.

Även om du kanske kan komma undan med att lägga 582 diff-listor i en fil, kan det vara klokare att gruppera relaterade patchar i separata filer ifall något går snett.

DIAGNOSTIK

Diagnostik indikerar i allmänhet att patch inte kunde tolka din patchfil.

Om optionen --verbose anges indikerar meddelandet Hmm... att det finns obearbetad text i patchfilen och att patch försöker härleda om det finns en patch i den texten och, i så fall, vilken typ av patch det är.

patchs avslutningsstatus är 0 om alla hunkar appliceras framgångsrikt, 1 om vissa hunkar inte kan appliceras eller om det finns merge-konflikter, och 2 om det finns allvarligare problem. När en uppsättning patchar appliceras i en loop bör du kontrollera denna avslutningsstatus så att du inte applicerar en senare patch på en delvis patchad fil.

VARNINGAR OCH BEGRÄNSNINGAR

Context-diffar kan inte tillförlitligt representera skapande eller borttagning av tomma filer, tomma kataloger eller specialfiler såsom symboliska länkar. De kan inte heller representera ändringar av filmetadata som ägarskap, behörigheter eller om en fil är en hård länk till en annan. Om sådana ändringar också krävs bör separata instruktioner, t.ex. ett shellskript, följa med patchen.

patch kan inte avgöra om radnumren är fel i ett ed-skript, och kan upptäcka dåliga radnummer i en normal diff endast när den hittar en ändring eller borttagning. En context-diff som använder fuzz-faktor 3 kan ha samma problem. Du bör förmodligen göra en context-diff i dessa fall för att se om ändringarna var rimliga. Att kompilera utan fel är förstås en ganska bra indikation på att patchen fungerade, men inte alltid.

patch producerar vanligen korrekta resultat, även när den måste gissa mycket. Resultaten garanteras dock bara vara korrekta när patchen appliceras på exakt samma version av filen som patchen genererades från.

KOMPATIBILITETSPROBLEM

POSIX-standarden specificerar beteende som skiljer sig från GNU patch.

• I POSIX patch, när -b inte används, görs inga säkerhetskopior även när det finns en missmatchning. I GNU patch aktiveras detta beteende med optionen --no-backup-if-mismatch, eller genom att följa POSIX med optionen --posix eller genom att sätta miljövariabeln POSIXLY_CORRECT.

• När namnet på filen som ska patchas härleds från patchhuvudet använder patch en komplicerad metod som valfritt följer POSIX. Metoden är ekvivalent med POSIX om filnamnen i context diff-huvudet och Index:-raden alla är identiska efter prefixborttagning. Din patch är normalt kompatibel om varje huvuds filnamn alla innehåller samma antal snedstreck.

• Begränsa dig till följande optioner när du skickar instruktioner avsedda att köras av vem som helst som kör GNU patch eller en patch som följer POSIX. Blanksteg är valfria i följande lista.

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

FEL

Rapportera fel via e-post till:

bug-patch@gnu.org

Om kod har duplicerats, till exempel med #ifdef OLDCODE ... #else ... #endif, är patch oförmögen att patcha båda versionerna, och, om det alls fungerar, kommer den sannolikt att patcha fel version och dessutom säga att den lyckades.

Om du applicerar en patch som du redan har applicerat tror patch att det är en omvänd patch och erbjuder sig att ta bort patchen. Detta skulle kunna tolkas som en funktion.

Att beräkna hur en hunk ska slås samman är betydligt svårare än att använda den vanliga fuzzy-algoritmen. Större hunkar, mer kontext, en större offset från den ursprungliga platsen och en sämre matchning gör alla algoritmen långsammare.

KOPIERING

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

FÖRFATTARE

Larry Wall skrev den ursprungliga versionen av patch. Paul Eggert tog bort patchs godtyckliga gränser; lade till stöd för binärfiler, att sätta filtider och att ta bort filer; och fick den att följa POSIX bättre. Andra bidragsgivare inkluderar Wayne Davison, som lade till unified-diff-stöd, och David MacKenzie, som lade till konfigurations- och säkerhetskopiestöd.

KOLOFON

Denna sida är en del av projektet patch, ett verktyg för att applicera diff-filer på original.

Information om projektet finns på:

https://savannah.gnu.org/projects/patch/

Om du har en felrapport för denna manualsida, skicka den till:

bug-patch@gnu.org

Denna sida hämtades från projektets uppströms Git-förråd:

git://git.savannah.gnu.org/patch.git

den 24 maj 2026.

Vid den tidpunkten var datumet för den senaste commit som hittades i förrådet 12 maj 2026.

Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller om du anser att det finns en bättre eller mer aktuell källa för sidan, eller om du har rättelser eller förbättringar av informationen i denna KOLOFON, som inte är en del av den ursprungliga manualsidan, skicka e-post till:

man-pages@man7.org

Sidslut

Orginalhemsidan på Engelska https://www.man7.org/linux/man-pages/man1/patch.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorservice som har sponsrat Linux.se med webbhotell.