LIBOF

Manuels pour la ligne de commande

Man » Manuel de patch en ligne - documentation en ligne détaillée pour la page de manuel de patch

🌍 ☰ 
patch - appliquer un fichier diff à un fichier original

SYNTAXE

patch [options] [fichier_original [fichier_patch]]

mais généralement :

patch -pnum <fichier_patch

DESCRIPTION

patch prend un fichier patch, `fichier_patch`, contenant une liste de différences générée par le programme `diff` et applique ces différences à un ou plusieurs fichiers originaux, produisant des versions corrigées. Normalement, les versions corrigées remplacent les fichiers originaux. Des sauvegardes peuvent être créées ; voir l'option `-b` ou `--backup`. Les noms des fichiers à corriger sont généralement extraits du fichier patch, mais si un seul fichier doit être corrigé, il peut être spécifié sur la ligne de commande en tant que `fichier_original`.

Au démarrage, patch tente de déterminer le type de la liste de différences, à moins que cela ne soit annulé par une option -c (--context), -e (--ed), -n (--normal) ou -u (--unified). Les différences de contexte (ancien style, nouveau style et unifié) et les différences normales sont appliquées par le programme patch lui-même, tandis que les différences ed sont simplement transmises au programme ed(1) via un pipe.

patch tente de sauter tout contenu superflu au début, d'appliquer la différence, puis de sauter tout contenu superflu à la fin. Ainsi, vous pouvez transmettre un message électronique contenant une liste de différences à patch, et cela devrait fonctionner. Si l'ensemble de la différence est indenté d'un montant constant, si les lignes se terminent par CRLF, ou si une différence est encapsulée une ou plusieurs fois en préfixant les lignes commençant par "-" comme spécifié dans le RFC 934 d'Internet, cela est pris en compte. Après avoir supprimé l'indentation ou l'encapsulation, les lignes commençant par # sont ignorées, car elles sont considérées comme des commentaires.

Avec les différences de contexte, et dans une moindre mesure avec les différences normales, patch peut détecter lorsque les numéros de ligne mentionnés dans le patch sont incorrects et tente de trouver le bon emplacement pour appliquer chaque bloc du patch. En premier lieu, il prend le numéro de ligne mentionné pour le bloc, plus ou moins tout décalage utilisé pour appliquer le bloc précédent. Si ce n'est pas le bon endroit, patch effectue une recherche à la fois vers l'avant et vers l'arrière pour trouver un ensemble de lignes correspondant au contexte donné dans le bloc. Tout d'abord, patch recherche un endroit où toutes les lignes du contexte correspondent. Si aucun endroit de ce type n'est trouvé, et qu'il s'agit d'une différence de contexte, et que le facteur de flou maximal est défini sur 1 ou plus, une autre recherche est effectuée en ignorant la première et la dernière ligne du contexte. Si cela échoue, et que le facteur de flou maximal est défini sur 2 ou plus, les deux premières et les deux dernières lignes du contexte sont ignorées, et une autre recherche est effectuée. (Le facteur de flou maximal par défaut est de 2.)

Les blocs avec moins de contexte de préfixe que de contexte de suffixe (après application du flou) doivent être appliqués au début du fichier si leur première ligne est 1. Les blocs avec plus de contexte de préfixe que de contexte de suffixe (après application du flou) doivent être appliqués à la fin du fichier.

Si un correctif ne parvient pas à trouver un emplacement pour installer un bloc du correctif, il place ce bloc dans un fichier de rejet, qui a généralement le même nom que le fichier de sortie, suivi d’un suffixe .rej, ou # si .rej générerait un nom de fichier trop long (si même l’ajout du caractère unique # rend le nom du fichier trop long, alors # remplace le dernier caractère du nom du fichier).

Le bloc rejeté est affiché au format diff unifié ou contextuel. Si l’entrée était un diff normal, la plupart des contextes sont simplement nuls. Les numéros de ligne des blocs dans le fichier de rejet peuvent être différents de ceux du fichier de correctif : ils reflètent l’emplacement approximatif où le correctif pense que les blocs rejetés doivent être placés dans le nouveau fichier, plutôt que dans l’ancien.

Au fur et à mesure que chaque bloc est traité, vous êtes informé si le bloc a échoué, et le cas échéant, à quelle ligne (dans le nouveau fichier) le correctif pensait que le bloc devait être placé. Si le bloc est installé à une ligne différente du numéro de ligne spécifié dans le diff, vous êtes informé du décalage. Un grand décalage peut indiquer qu’un bloc a été installé au mauvais endroit. Vous êtes également informé si un facteur de flou a été utilisé pour effectuer la correspondance, auquel cas vous devez également être un peu suspicieux. Si l’option --verbose est spécifiée, vous êtes également informé des blocs qui correspondent exactement.

Si aucun fichier d’origine (origfile) n’est spécifié dans la ligne de commande, patch tente de déterminer à partir des données d’en-tête le nom du fichier à modifier, en utilisant les règles suivantes.

Tout d’abord, patch prend une liste ordonnée de noms de fichiers candidats comme suit :

Si l’en-tête est celui d’un diff contextuel, patch prend les anciens et nouveaux noms de fichiers dans l’en-tête. Un nom est ignoré s’il ne contient pas suffisamment de barres obliques pour satisfaire l’option -pnum ou --strip=num. Le nom /dev/null est également ignoré.

S’il existe une ligne Index : dans les données d’en-tête et que soit les anciens et nouveaux noms sont absents, soit que patch est conforme à POSIX, patch prend le nom dans la ligne Index :.

Aux fins des règles suivantes, les noms de fichiers candidats sont considérés dans l’ordre (ancien, nouveau, index), quel que soit l’ordre dans lequel ils apparaissent dans l’en-tête.

Ensuite, patch sélectionne un nom de fichier dans la liste des candidats comme suit :

Si certains des fichiers nommés existent, patch sélectionne le premier nom s’il est conforme à POSIX, et le meilleur nom dans le cas contraire.

Si patch n’ignore pas RCS, ClearCase, Perforce et SCCS (voir l’option -g num ou --get=num), et qu’aucun des fichiers nommés n’existe mais qu’un maître RCS, ClearCase, Perforce ou SCCS est trouvé, patch sélectionne le premier nom de fichier avec un maître RCS, ClearCase, Perforce ou SCCS.

S’il n’existe aucun fichier nommé, aucun maître RCS, ClearCase, Perforce ou SCCS n’a été trouvé, certains noms sont donnés, patch n’est pas conforme à POSIX, et le correctif semble créer un fichier, patch sélectionne le meilleur nom qui nécessite la création du moins de répertoires.

Si aucun nom de fichier n’est obtenu à partir des heuristiques ci-dessus, on vous demande le nom du fichier à modifier, et patch sélectionne ce nom.

Pour déterminer le meilleur nom de fichier dans une liste non vide, patch prend d’abord tous les noms avec le moins grand nombre de composants de chemin ; parmi ceux-ci, il prend ensuite tous les noms avec le nom de base le plus court ; parmi ceux-ci, il prend ensuite tous les noms les plus courts ; enfin, il prend le premier nom restant.

De plus, si les données inutiles au début contiennent une ligne Prereq :, patch prend le premier mot de la ligne des prérequis (généralement un numéro de version) et vérifie si ce mot peut être trouvé dans le fichier d’origine. Si ce n’est pas le cas, patch demande une confirmation avant de continuer.

Le résultat de tout cela est que vous devriez pouvoir exécuter une commande shell comme celle-ci :

patch -d /usr/src/local/blurfl

et appliquer un fichier de correctif à un fichier dans le répertoire blurfl directement à partir d’un correctif lu à partir de l’entrée standard.

Si le fichier de correctif contient plus d’un correctif, patch tente d’appliquer chacun d’eux comme s’ils provenaient de fichiers de correctif distincts. Cela signifie, entre autres, qu’il est supposé que le nom du fichier à modifier doit être déterminé pour chaque liste de différences, et que les données inutiles avant chaque liste de différences contiennent des éléments intéressants tels que les noms de fichiers et les niveaux de révision, comme mentionné précédemment.

OPTIONS

-b ou --backup
Crée des fichiers de sauvegarde. Autrement dit, lorsqu’un fichier est modifié, l’original est renommé ou copié au lieu d’être supprimé. Voir l’option -V ou --version-control pour plus de détails sur la façon dont les noms des fichiers de sauvegarde sont déterminés.

--backup-if-mismatch
Crée une sauvegarde d’un fichier si le correctif ne correspond pas exactement au fichier et si les sauvegardes ne sont pas demandées par d’autres moyens. C’est la valeur par défaut, sauf si patch est conforme à POSIX.

--no-backup-if-mismatch
Ne crée pas de sauvegarde d’un fichier si le correctif ne correspond pas exactement au fichier et si les sauvegardes ne sont pas demandées par d’autres moyens. C’est la valeur par défaut si patch est conforme à POSIX.

-B pref ou --prefix=pref
Utilise la méthode simple pour déterminer les noms des fichiers de sauvegarde (voir la méthode -V ou l’option --version-control) et ajoute pref à un nom de fichier lors de la génération de son nom de fichier de sauvegarde. Par exemple, avec -B /junk/, le nom de fichier de sauvegarde simple pour src/patch/util.c est /junk/src/patch/util.c.

--binary
Écrit tous les fichiers en mode binaire, à l’exception de la sortie standard et de /dev/tty. Lors de la lecture, désactive l’heuristique permettant de transformer les fins de ligne CRLF en fins de ligne LF. Cette option est nécessaire sur les systèmes POSIX lors de l’application de correctifs générés sur des systèmes non POSIX à des fichiers non POSIX. (Sur les systèmes POSIX, les lectures et les écritures de fichiers ne transforment jamais les fins de ligne. Sous Windows, les lectures et les écritures transforment les fins de ligne par défaut, et les correctifs doivent être générés par diff --binary lorsque les fins de ligne sont importantes.)

-c ou --context
Interprète le fichier de correctif comme un correctif contextuel ordinaire.

-d dir ou --directory=dir
Change de répertoire en dir immédiatement, avant de faire autre chose.

-D define  ou  --ifdef=define

Utiliser la construction #ifdef ... #endif pour marquer les modifications, avec define comme symbole de différenciation.

--dry-run

Afficher les résultats de l'application des correctifs sans modifier réellement aucun fichier.

-e  ou  --ed

Interpréter le fichier de correctif comme un script ed.

-E  ou  --remove-empty-files

Supprimer les fichiers de sortie qui sont vides après l'application des correctifs. Normalement, cette option est inutile, car patch peut examiner les horodatages de l'en-tête pour déterminer si un fichier doit exister après le patch. Cependant, si l'entrée n'est pas un diff contextuel ou si patch est conforme à POSIX, patch ne supprime pas les fichiers patchés vides à moins que cette option ne soit donnée. Lorsque patch supprime un fichier, il tente également de supprimer tout répertoire parent vide.

-f  ou  --force

Supposer que l'utilisateur sait exactement ce qu'il fait, et ne poser aucune question. Ignorer les correctifs dont les en-têtes n'indiquent pas quel fichier doit être patché ; patcher les fichiers même s'ils ont la mauvaise version pour la ligne Prereq: dans le correctif ; et supposer que les correctifs ne sont pas inversés même s'ils semblent l'être. Cette option ne supprime pas les commentaires ; utilisez -s pour cela.

-F num  ou  --fuzz=num

Définir le facteur d'imprécision maximal. Cette option ne s'applique qu'aux diffs qui ont du contexte, et amène patch à ignorer jusqu'à ce nombre de lignes de contexte lors de la recherche d'endroits où installer un segment. Notez qu'un facteur d'imprécision plus élevé augmente les risques d'un correctif défectueux. Le facteur d'imprécision par défaut est 2. Un facteur d'imprécision supérieur ou égal au nombre de lignes de contexte dans le diff contextuel, ordinairement 3, ignore tout le contexte.

-g num  ou  --get=num

Cette option contrôle les actions de patch lorsqu'un fichier est sous contrôle RCS ou SCCS, et n'existe pas ou est en lecture seule et correspond à la version par défaut, ou lorsqu'un fichier est sous contrôle ClearCase ou Perforce et n'existe pas. Si num est positif, patch obtient (ou extrait) le fichier du système de contrôle de révision ; si zéro, patch ignore RCS, ClearCase, Perforce et SCCS et n'obtient pas le fichier ; et si négatif, patch demande à l'utilisateur s'il faut obtenir le fichier. La valeur par défaut de cette option est donnée par la valeur de la variable d'environnement PATCH_GET si elle est définie ; sinon, la valeur par défaut est zéro.

--help

Afficher un résumé des options et quitter.

-i fichier_correctif  ou  --input=fichier_correctif

Lire le correctif depuis fichier_correctif. Si fichier_correctif est -, lire depuis l'entrée standard, la valeur par défaut.

-l  ou  --ignore-whitespace

Faire correspondre les motifs de manière approximative, au cas où des tabulations ou des espaces auraient été altérés dans vos fichiers. Toute séquence d'un ou plusieurs blancs dans le fichier de correctif correspond à toute séquence dans le fichier original, et les séquences de blancs en fin de ligne sont ignorées. Les caractères normaux doivent toujours correspondre exactement. Chaque ligne du contexte doit toujours correspondre à une ligne dans le fichier original.

--merge ou --merge=merge ou --merge=diff3

Fusionner un fichier de correctif dans les fichiers originaux de manière similaire à diff3(1) ou merge(1). Si un conflit est trouvé, patch émet un avertissement et encadre le conflit avec des lignes <<<<<<< et >>>>>>>. Un conflit typique ressemblera à ceci :

<<<<<<<
lignes du fichier original
|||||||
lignes originales du correctif
=======
nouvelles lignes du correctif
>>>>>>>

L’argument optionnel de --merge détermine le format de sortie pour les conflits : le format diff3 affiche la section ||||||| avec les lignes originales du correctif ; dans le format merge, cette section est absente. Le format merge est la valeur par défaut.

Cette option implique --forward et ne prend pas en compte l’option --fuzz=num.

-n ou --normal
Interpréter le fichier de correctif comme un correctif normal.

-N ou --forward
Lorsqu’un correctif ne s’applique pas, patch vérifie généralement si le correctif semble déjà avoir
été appliqué en essayant d’annuler l’application du premier bloc. L’option --forward empêche cela.
Voir également -R.

-o outfile ou --output=outfile
Envoyer la sortie vers outfile au lieu de modifier les fichiers sur place. Ne pas utiliser cette
option si outfile est l’un des fichiers à modifier. Lorsque outfile est -, envoyer la sortie vers
la sortie standard et envoyer tous les messages qui seraient normalement envoyés vers la sortie
standard vers la sortie d’erreur standard.

-pnum ou --strip=num
Supprimer le plus petit préfixe contenant num barres obliques en tête de chaque nom de fichier
trouvé dans le fichier de correctif. Une séquence d’une ou plusieurs barres obliques adjacentes
est comptée comme une seule barre oblique. Cela contrôle la manière dont les noms de fichiers
trouvés dans le fichier de correctif sont traités, au cas où vous conserveriez vos fichiers dans
un répertoire différent de celui de la personne qui a envoyé le correctif. Par exemple, en
supposant que le nom de fichier dans le fichier de correctif est

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

la définition de -p0 donne le nom de fichier entier sans modification, -p1 donne

u/howard/src/blurfl/blurfl.c

sans la barre oblique en tête, -p4 donne

blurfl/blurfl.c

et la non-spécification de -p donne simplement blurfl.c. Ce que vous obtenez est recherché soit
dans le répertoire actuel, soit dans le répertoire spécifié par l’option -d.

--posix
Se conformer plus strictement à la norme POSIX, comme suit.

Utiliser le premier fichier existant de la liste (ancien, nouveau, index) lors de la déduction des
noms de fichiers à partir des en-têtes diff.

Ne pas supprimer les fichiers qui sont vides après l’application du correctif.

Ne pas demander si les fichiers doivent être récupérés à partir de RCS, ClearCase, Perforce ou SCCS.

Exiger que toutes les options précèdent les fichiers dans la ligne de commande.

Ne pas créer de sauvegarde des fichiers en cas de divergence.

--quoting-style=word
Utiliser le style word pour la citation des noms de fichiers en sortie. Le mot doit être l’un des
suivants :

literal
Afficher les noms de fichiers tels quels.

shell
Citer les noms de fichiers pour le shell s’ils contiennent des métacaractères shell ou causeraient une
sortie ambiguë.

shell-always
Citer les noms de fichiers pour le shell, même s’ils n’en auraient normalement pas besoin.

c
Citer les noms de fichiers comme pour une chaîne de caractères en langage C.

escape
Citer comme avec c, mais omettre les caractères de guillemets environnants.

Vous pouvez spécifier la valeur par défaut de l’option --quoting-style avec la variable d’environnement QUOTING_STYLE. Si cette variable d’environnement n’est pas définie, la valeur par défaut est shell.

-r rejectfile ou --reject-file=rejectfile
Place les éléments rejetés dans le fichier rejectfile au lieu du fichier .rej par défaut. Si rejectfile est -, les éléments rejetés sont supprimés.

-R ou --reverse
Suppose que ce correctif a été créé avec les fichiers ancien et nouveau inversés. patch tente d’inverser chaque bloc avant de l’appliquer. Les éléments rejetés sont générés dans le format inversé. L’option -R ne fonctionne pas avec les scripts de diff ed, car il y a trop peu d’informations pour reconstruire l’opération inverse.

Si le premier bloc d’un correctif échoue, patch inverse le bloc pour voir s’il peut être appliqué ainsi. Si c’est le cas, on vous demande si vous souhaitez définir l’option -R. Si ce n’est pas le cas, le correctif continue d’être appliqué normalement. (Remarque : cette méthode ne peut pas détecter un correctif inversé s’il s’agit d’un diff normal et si la première commande est une insertion (c’est-à-dire qu’elle aurait dû être une suppression), car les insertions réussissent toujours, en raison du fait qu’un contexte nul correspond n’importe où. Heureusement, la plupart des correctifs ajoutent ou modifient des lignes plutôt que de les supprimer, de sorte que la plupart des diffs normaux inversés commencent par une suppression, ce qui échoue et déclenche l’heuristique.)

--read-only=behavior
Se comporter comme demandé lorsque l’on tente de modifier un fichier en lecture seule : ignorer le problème potentiel, afficher un avertissement à ce sujet (par défaut) ou échouer.

--reject-format=format
Produire des fichiers de rejet dans le format spécifié (soit contexte, soit unifié). Sans cette option, les blocs rejetés sont générés au format diff unifié si le correctif d’entrée est dans ce format, sinon dans un format diff de contexte ordinaire.

-s ou --silent ou --quiet
Fonctionner en silence, sauf en cas d’erreur.

--follow-symlinks
Lors de la recherche de fichiers d’entrée, suivre les liens symboliques. Remplace les liens symboliques au lieu de modifier les fichiers vers lesquels pointent les liens symboliques. Les correctifs de type Git vers des liens symboliques ne s’appliqueront plus. Cette option existe pour la compatibilité avec les versions antérieures de patch ; son utilisation est déconseillée.

-t ou --batch
Supprimer les questions comme -f, mais faire d’autres hypothèses : ignorer les correctifs dont les en-têtes ne contiennent pas de noms de fichiers (comme avec -f) ; ignorer les correctifs pour lesquels le fichier a la mauvaise version pour la ligne Prereq ; et supposer que les correctifs sont inversés s’ils semblent l’être.

-T ou --set-time
Définir les heures de modification et d’accès des fichiers corrigés à partir des horodatages donnés dans les en-têtes de diff de contexte. À moins que spécifié dans les horodatages, supposer que les en-têtes de diff de contexte utilisent l’heure locale.

L’utilisation de cette option avec des horodatages qui n’incluent pas de fuseaux horaires n’est pas recommandée, car les correctifs utilisant l’heure locale ne peuvent pas facilement être utilisés par des personnes situées dans d’autres fuseaux horaires, et parce que les horodatages locaux sont ambigus lorsque les horloges locales sont décalées en arrière pendant les changements d’heure d’été. Assurez-vous que les horodatages incluent des fuseaux horaires, ou générez des correctifs avec UTC et utilisez l’option -Z ou --set-utc à la place.

-u ou --unified
Interpréter le fichier de patch comme un diff contextuel unifié.

-v ou --version
Afficher l’en-tête et le niveau de révision du patch, puis quitter.

-V méthode ou --version-control=méthode
Utiliser la méthode pour déterminer les noms des fichiers de sauvegarde. La méthode peut également être spécifiée par la variable d’environnement PATCH_VERSION_CONTROL (ou, si celle-ci n’est pas définie, la variable VERSION_CONTROL), qui est remplacée par cette option. La méthode n’affecte pas la création des fichiers de sauvegarde ; elle affecte uniquement les noms des fichiers de sauvegarde qui sont créés.

La valeur de méthode est similaire à la variable version-control de GNU Emacs ; patch reconnaît également des synonymes plus descriptifs. Les valeurs valides pour méthode sont (des abréviations uniques sont acceptées) :

existing ou nil
Créer des sauvegardes numérotées des fichiers qui en ont déjà, sinon créer des sauvegardes simples. C’est la valeur par défaut.

numbered ou t
Créer des sauvegardes numérotées. Le nom du fichier de sauvegarde numéroté pour F est F.~N~, où N est le numéro de version.

simple ou never
Créer des sauvegardes simples. Les options -B ou --prefix, -Y ou --basename-prefix et -z ou --suffix spécifient le nom du fichier de sauvegarde simple. Si aucune de ces options n’est donnée, une suffixe de sauvegarde simple est utilisé ; il s’agit de la valeur de la variable d’environnement SIMPLE_BACKUP_SUFFIX si elle est définie, et est .orig sinon.

Avec des sauvegardes numérotées ou simples, si le nom du fichier de sauvegarde est trop long, le suffixe de sauvegarde ~ est utilisé à la place ; si même l’ajout de ~ rendrait le nom trop long, alors ~ remplace le dernier caractère du nom du fichier.

--verbose
Afficher des informations supplémentaires sur le travail effectué.

-x num ou --debug=num
Définir les drapeaux de débogage internes qui intéressent uniquement les programmeurs de patch.

-Y pref ou --basename-prefix=pref
Utiliser la méthode simple pour déterminer les noms des fichiers de sauvegarde (voir l’option -V méthode ou --version-control méthode), et préfixer pref au nom de base d’un fichier lors de la génération de son nom de fichier de sauvegarde. Par exemple, avec -Y .del/ le nom du fichier de sauvegarde simple pour src/patch/util.c est src/patch/.del/util.c.

-z suffix ou --suffix=suffix
Utiliser la méthode simple pour déterminer les noms des fichiers de sauvegarde (voir l’option -V méthode ou --version-control méthode), et utiliser suffix comme suffixe. Par exemple, avec -z - le nom du fichier de sauvegarde pour src/patch/util.c est src/patch/util.c-.

-Z ou --set-utc
Définir les heures de modification et d’accès des fichiers corrigés à partir des horodatages donnés dans les en-têtes des diffs contextuels. Sauf indication contraire dans les horodatages, supposer que les en-têtes des diffs contextuels utilisent le temps univers coordonné (UTC, souvent appelé GMT). Voir également l’option -T ou --set-time.

Les options -Z ou --set-utc et -T ou --set-time ne modifient normalement pas l’heure d’un fichier si l’heure d’origine du fichier ne correspond pas à l’heure donnée dans l’en-tête du patch, ou si son contenu ne correspond pas exactement au patch. Cependant, si l’option -f ou --force est donnée, l’heure du fichier est définie quoi qu’il en soit.

En raison des limitations du format de sortie de diff, ces options ne peuvent pas mettre à jour les horodatages des fichiers dont le contenu n'a pas changé. De plus, si vous utilisez ces options, vous devez supprimer (par exemple, avec make clean) tous les fichiers qui dépendent des fichiers corrigés, afin que les invocations ultérieures de make ne soient pas confuses par les horodatages des fichiers corrigés.

ENVIRONNEMENT

PATCH_GET
Indique si `patch` doit récupérer par défaut les fichiers manquants ou en lecture seule à partir de RCS, ClearCase, Perforce ou SCCS ; voir l'option `-g` ou `--get`.

POSIXLY_CORRECT
Si cette variable est définie, `patch` se conforme plus strictement à la norme POSIX par défaut ; voir l'option `--posix`.

QUOTING_STYLE
Valeur par défaut de l'option `--quoting-style`.

SIMPLE_BACKUP_SUFFIX
Extension à utiliser pour les noms de fichiers de sauvegarde simples au lieu de `.orig`.

TMPDIR, TMP, TEMP
Répertoire dans lequel placer les fichiers temporaires ; `patch` utilise la première variable d'environnement de cette liste qui est définie. Si aucune n'est définie, la valeur par défaut dépend du système ; il s'agit généralement de `/tmp` sur les hôtes Unix.

VERSION_CONTROL ou PATCH_VERSION_CONTROL
Sélectionne le style de contrôle de version ; voir l'option `-v` ou `--version-control`.

FICHIERS

$TMPDIR/p*
fichiers temporaires

/dev/tty
terminal de contrôle ; utilisé pour obtenir les réponses aux questions posées à l'utilisateur

VOIR AUSSI

[diff]({filename}../../diff)(1), ed(1), merge(1).

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

NOTES POUR LES AUTEURS DE PATCHS

Il y a plusieurs choses que vous devez garder à l'esprit si vous comptez envoyer des correctifs.

Créez votre correctif de manière systématique. Lorsque vous utilisez un système de contrôle de version, cela devrait être facile ; par exemple, avec Git, vous pouvez utiliser git diff. Sinon, une bonne méthode consiste à utiliser la commande diff -Naur old new, où old et new identifient les anciens et les nouveaux répertoires. Les noms old et new ne doivent pas contenir de barres obliques.

Si le correctif doit communiquer les horodatages des fichiers ainsi que le contenu des fichiers, les en-têtes des commandes diff doivent contenir des dates et des heures en temps universel en utilisant le format Unix traditionnel, afin que les destinataires du correctif puissent utiliser l'option -Z ou --set-utc. Voici un exemple de commande pour générer de tels en-têtes, en utilisant la syntaxe de Bourne shell :

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

Indiquez à vos destinataires comment appliquer le correctif en leur indiquant dans quel répertoire se rendre et quelles options de patch utiliser. La chaîne d'options -Np1 est recommandée. Testez votre procédure en faisant semblant d'être un destinataire et en appliquant votre correctif à une copie des fichiers originaux.

Vous pouvez éviter à vos destinataires de nombreux problèmes en conservant un fichier patchlevel.h qui est corrigé pour incrémenter le niveau de correctif en tant que premier diff dans le fichier de correctif que vous envoyez. Si vous placez une ligne Prereq : avec le correctif, cela ne leur permettra pas d'appliquer les correctifs dans le mauvais ordre sans aucun avertissement.

Vous pouvez créer un fichier en envoyant un diff qui compare /dev/null ou un fichier vide daté de l'époque (1970-01-01 00:00:00 UTC) au fichier que vous souhaitez créer. Cela ne fonctionne que si le fichier que vous souhaitez créer n'existe pas déjà dans le répertoire cible. Inversement, vous pouvez supprimer un fichier en envoyant un diff contextuel qui compare le fichier à supprimer à un fichier vide daté de l'époque. Le fichier sera supprimé, à moins que patch ne respecte la norme POSIX et que l'option -E ou --remove-empty-files ne soit pas spécifiée. Un moyen simple de générer des patchs qui créent et suppriment des fichiers est d'utiliser l'option -N ou --new-file de GNU diff.

Si le destinataire est censé utiliser l'option -pN, ne transmettez pas une sortie qui ressemble à ceci :

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

parce que les deux noms de fichiers ont un nombre différent de barres obliques, et que différentes versions de patch interprètent les noms de fichiers différemment. Pour éviter toute confusion, envoyez plutôt une sortie qui ressemble à ceci :

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

Évitez d'envoyer des patchs qui comparent des noms de fichiers de sauvegarde comme README.orig, car cela pourrait amener patch à appliquer le patch à un fichier de sauvegarde au lieu du fichier réel. Envoyez plutôt des patchs qui comparent les mêmes noms de fichiers de base dans différents répertoires, par exemple old/README et new/README.

Veillez à ne pas envoyer de patchs inversés, car cela amène les gens à se demander s'ils ont déjà appliqué le patch.

Essayez de ne pas inclure dans votre patch des modifications apportées aux fichiers dérivés (par exemple, le fichier configure où il y a une ligne configure : configure.ac dans votre fichier Makefile), car le destinataire devrait être en mesure de régénérer les fichiers dérivés de toute façon. Si vous devez envoyer des diffs de fichiers dérivés, générez les diffs en utilisant UTC, demandez aux destinataires d'appliquer le patch avec l'option -Z ou --set-utc, et demandez-leur de supprimer les fichiers non corrigés qui dépendent des fichiers corrigés (par exemple, avec make clean).

Bien que vous puissiez vous en sortir en plaçant 582 listes de diff dans un seul fichier, il serait peut-être plus judicieux de regrouper les patchs associés dans des fichiers distincts, au cas où quelque chose se passerait mal.

DIAGNOSTICS

Les diagnostics indiquent généralement que patch n'a pas pu analyser votre fichier de patch.

Si l'option --verbose est spécifiée, le message Hmm... indique qu'il y a du texte non traité dans le fichier de patch et que patch tente de déduire s'il y a un patch dans ce texte et, le cas échéant, de quel type de patch il s'agit.

Le code de sortie de patch est 0 si tous les blocs sont appliqués avec succès, 1 si certains blocs ne peuvent pas être appliqués ou s'il y a des conflits de fusion, et 2 s'il y a des problèmes plus graves. Lors de l'application d'un ensemble de patchs dans une boucle, il est important de vérifier ce code de sortie afin de ne pas appliquer un patch ultérieur à un fichier partiellement corrigé.

AVERTISSEMENTS

Les diffs contextuels ne peuvent pas représenter de manière fiable la création ou la suppression de fichiers vides, de répertoires vides ou de fichiers spéciaux tels que les liens symboliques. Ils ne peuvent pas non plus représenter les modifications des métadonnées des fichiers, telles que la propriété, les permissions ou le fait qu'un fichier est un lien physique vers un autre. Si des modifications de ce type sont également nécessaires, des instructions distinctes (par exemple, un script shell) pour les effectuer doivent accompagner le patch.

patch ne peut pas vérifier si les numéros de ligne sont incorrects dans un script ed, et ne peut détecter les mauvais numéros de ligne dans une simple comparaison (diff) que lorsqu’il trouve une modification ou une suppression. Une comparaison contextuelle utilisant un facteur de flou de 3 peut avoir le même problème. Vous devriez probablement effectuer une comparaison contextuelle dans ces cas pour voir si les modifications étaient logiques. Bien sûr, la compilation sans erreurs est une bonne indication que le correctif a fonctionné, mais pas toujours.

patch produit généralement les résultats corrects, même lorsqu’il doit faire beaucoup de suppositions. Cependant, les résultats ne sont garantis corrects que lorsque le correctif est appliqué exactement à la même version du fichier à partir duquel il a été généré.

PROBLÈMES DE COMPATIBILITÉ

La norme POSIX spécifie un comportement différent de GNU patch.

Dans POSIX patch, lorsqu’on n’utilise pas l’option -b, les sauvegardes ne sont pas créées, même en cas de divergence. Dans GNU patch, ce comportement est activé avec l’option --no-backup-if-mismatch, ou en se conformant à POSIX avec l’option --posix, ou en définissant la variable d’environnement POSIXLY_CORRECT.

Lorsqu’il déduit le nom du fichier à corriger à partir de l’en-tête du correctif, patch utilise une méthode complexe qui est facultativement conforme à POSIX. La méthode est équivalente à POSIX si les noms de fichiers dans l’en-tête de la comparaison contextuelle et la ligne Index: sont tous identiques après suppression des préfixes. Votre correctif est normalement compatible si les noms de fichiers de chaque en-tête contiennent tous le même nombre de barres obliques.

Limitez-vous aux options suivantes lorsque vous envoyez des instructions destinées à être exécutées par quiconque utilisant GNU patch ou un correctif conforme à POSIX. Les espaces sont facultatifs dans la liste suivante.

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

BUGS

Veuillez signaler les bogues par e-mail à <_>.

Si du code a été dupliqué (par exemple, avec #ifdef OLDCODE ... #else ... #endif), patch est incapable de corriger les deux versions, et, si cela fonctionne, il corrigera probablement la mauvaise version, et vous indiquera qu’il a réussi.

Si vous appliquez un correctif que vous avez déjà appliqué, patch pense qu’il s’agit d’un correctif inversé et propose de supprimer le correctif. Cela pourrait être considéré comme une fonctionnalité.

Le calcul de la manière de fusionner un bloc est beaucoup plus difficile que l’utilisation de l’algorithme de recherche floue standard. Les grands blocs, plus de contexte, un décalage plus important par rapport à l’emplacement d’origine et une moins bonne correspondance ralentissent tous l’algorithme.

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

La permission est accordée de créer et de distribuer des copies textuelles de ce manuel à condition que l’avis de copyright et cet avis de permission soient conservés sur toutes les copies.

Il est permis de copier et de distribuer des versions modifiées de ce manuel, aux conditions suivantes : la copie intégrale est autorisée, à condition que l’ensemble de l’œuvre dérivée résultante soit distribué selon les termes d’un avis de permission identique à celui-ci.

Il est permis de copier et de distribuer des traductions de ce manuel dans une autre langue, aux conditions susmentionnées pour les versions modifiées, à ceci près que cet avis de permission peut être inclus dans les traductions approuvées par les détenteurs des droits d’auteur au lieu de figurer dans la version anglaise originale.

AUTEURS

Larry Wall a écrit la version originale de patch. Paul Eggert a supprimé les limites arbitraires de patch, a ajouté la prise en charge des fichiers binaires, la définition des dates et heures des fichiers et la suppression de fichiers, et l’a rendu plus conforme à POSIX. Parmi les autres contributeurs, on peut citer Wayne Davison, qui a ajouté la prise en charge de unidiff, et David MacKenzie, qui a ajouté la prise en charge de la configuration et des sauvegardes. Andreas Gruenbacher a ajouté la prise en charge de la fusion.