Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	.ta 3n [size=18] [b]Nom[/b] [/size] patch - appliquer un fichier diff à un original [size=18] [b]Résumé[/b] [/size] [b]patch[/b] [i][ options ][/i] [i][ fichier-original[/i] [i][ fichier-patch ]][/i] .Sp mais habituellement simplement .Sp [b][i]patch -p nombre[/i][/b] [b][i]< fichier-patch[/i][/b] [size=18] [b]Description[/b] [/size] [b]patch[/b] utilise un [i]fichier-patch[/i] contenant un listing de différences produit par le programme [b]diff[/b] et applique ces différences à un ou plusieurs fichiers originaux, en produisant des versions patchées. Normalement, les versions patchées remplacent les originaux. Des sauvegardes peuvent être créées ; voyez l'option [b]-b[/b] ou [b]=backup .[/b] Le nom des fichiers à patcher est habituellement composé à partir de celui du fichier patch, mais s'il n'y a qu'un seul fichier à patcher, il peut être spécifié sur la ligne de commandes comme [b]fichier-original .[/b] Au démarrage, patch essaie de déterminer le type du listing de diff, à moins qu'il ne soit contraint par une option [b][/b]-c ([b][/b]=context), [b][/b]-e ([b][/b]=ed), [b][/b]-n ([b][/b]=normal) ou [b][/b]-u ([b][/b]=unified). Les diffs contextuels (ancien style, nouveau style et unifié) et les diffs normaux sont appliqués par le programme [b]patch[/b] lui-même, alors que les diffs [b]ed[/b] sont simplement fournis à l'éditeur [b]ed (1)[/b] via un tube. [b]patch[/b] essaie de sauter par dessus les déchets de tête, appliquer le diff, et ensuite passer les déchets de fin. Par conséquent, vous pourriez pouvoir alimenter facilement [b]patch[/b] en lui injectant un article ou un message contenant un listing diff. Si le diff entier est fortement indenté, ou si un diff contextuel contient des lignes se terminant par s-1CRLFs0 ou est encapsulé une ou plusieurs fois en préfixant les lignes débutant par "[b][/b]-" par "[b][/b]- " comme spécifié par le RFC Internet 934, cela est pris en considération. Avec les diffs contextuels, et dans une moindre mesure avec les diffs normaux, [b]patch[/b] peut détecter si les numéros de lignes mentionnés dans le patch sont incorrects, et essayer de trouver l'endroit correct où appliquer chaque composant du patch (hunk). En première approximation, il prend le numéro de ligne mentionné par le composant, plus ou moins le décalage utilisé lors de l'application du composant précédent. Si ce n'est pas l'endroit correct, [b]patch[/b] recherche en avant et en arrière un groupe de lignes correspondant au contexte donné par le composant. D'abord, [b]patch[/b] recherche un endroit où toutes les lignes du contexte correspondent. S'il ne trouve pas de tel emplacement, et si c'est un diff contextuel, et que le facteur de bruit (fuzz factor) maximum vaut 1 ou plus, alors une autre analyse a lieu ; celle-ci ignore la première et la dernière ligne de contexte. Si cela échoue, et que le facteur de bruit maximum est supérieur ou égal à 2, les deux premières et les deux dernières lignes de contexte sont ignorées, et une autre analyse est faite (le facteur de bruit maximum par défaut est 2). Si [b]patch[/b] ne peut trouver d'endroit où installer ce composant du patch, il place le composant dans un fichier de rejet, qui est normalement le nom du fichier de sortie plus un suffixe [b].rej ,[/b] ou [b]#[/b] si [b].rej[/b] générerait un nom de fichier trop long (si même la concaténation du seul caractère [b]#[/b] rend le nom de fichier trop long, alors [b]#[/b] remplace le dernier caractère du nom de fichier). (Le composant rejeté apparaît dans la forme diff contextuelle ordinaire quelle que soit la forme du patch d'entrée. Si l'entrée est un diff normal, beaucoup de contextes sont tout simplement vides.) Les numéros de ligne des composants dans le fichier de rejet peuvent être différents de ceux du fichier patch : ils reflètent l'endroit approximatif des composants ayant échoué dans le nouveau fichier plutôt que dans l'ancien. Après chaque tentative d'application de composant, [b]patch[/b] vous indique si le composant a échoué et, si c'est le cas, à quelle ligne (du nouveau fichier) le composant aurait dû être placé. Si le composant est installé à une ligne différente du numéro de ligne spécifié dans le diff, le décalage utilisé est indiqué. Un seul grand décalage [i]peut[/i] indiquer qu'un composant a été installé au mauvais endroit. On vous signale également si un facteur de bruit a été utilisé pour trouver la correspondance, auquel cas vous devriez également être légèrement suspicieux. Si l'option [b]=verbose[/b] est donnée, les composants correspondant exactement sont également mentionnés. Si aucun [i]fichier-original[/i] n'est spécifié sur la ligne de commandes, [b]patch[/b] essaie de déterminer à partir des déchets de tête le nom du fichier à éditer, en utilisant les règles suivantes :     D'abord, [b]patch[/b] construit une liste ordonnée de noms de fichiers candidats comme suit : [b] (bu[/b] [table][row][col]    [/col][col]Si l'en-tête est celui d'un diff contextuel, [b]patch[/b] extrait le nom des anciens et des nouveaux fichiers de l'en-tête. Un nom est ignoré s'il ne contient pas suffisamment de slashs pour satisfaire à l'option [b][i]-p nombre[/i][/b] ou [b][i]=strip= nombre[/i][/b] &. Le nom [b]/dev/null[/b] est également ignoré.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]S'il y a une ligne [b]Index:&[/b] dans les déchets de tête et que les anciens et nouveaux noms sont absents, ou que [b]patch[/b] se conforme à s-1POSIXs0, [b]patch[/b] extraira le nom à partir de la ligne [b]Index:& .[/b][/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Dans les règles suivantes, les noms de fichiers candidats sont considérés être placés dans l'ordre (ancien, nouveau, index), quel que soit leur ordre d'apparition dans l'en-tête.[/col][/row][/table]     Ensuite, [b]patch[/b] sélectionne un nom de fichier à partir de la liste de candidats comme suit : [b] (bu[/b] [table][row][col]    [/col][col]Si certains des fichiers nommés existent, [b]patch[/b] sélectionne le premier nom s'il est conforme à s-1POSIXs0, ou le meilleur nom sinon.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Si [b]patch[/b] n'ignore pas s-1RCSs0, ClearCase et s-1SCCSs0 (voyez l'option [b][i]-g nombre[/i][/b] ou [b][/b]=get=[i]nombre[/i]), et si aucun des fichiers nommés n'existe mais qu'un document maître s-1RCSs0, ClearCase ou s-1SCCSs0 est trouvé, [b]patch[/b] sélectionne le premier fichier nommé ayant un document maître s-1RCSs0, ClearCase ou s-1SCCSs0.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Si aucun des fichiers nommés n'existe et qu'aucun document maître s-1RCSs0, ClearCase ou s-1SCCSs0 n'a été trouvé, si des noms sont fournis, si [b]patch[/b] ne se conforme pas à s-1POSIXs0, et si le patch semble créer un fichier, [b]patch[/b] sélectionne le meilleur nom requérant la création du plus petit nombre de répertoires.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Si aucun nom de fichier ne résulte des heuristiques ci-dessus, on vous demandera le nom du fichier à patcher, et [b]patch[/b] sélectionnera ce nom.[/col][/row][/table]     Pour déterminer le [i]meilleur[/i] nom d'une liste non vide de noms de fichiers, [b]patch[/b] considère d'abord tous les noms ayant le composant de nom de chemin le plus court ; parmi ceux-ci, il prend ensuite ceux de nom de base le plus court ; parmi les rescapés, il prend ensuite tous les noms les plus courts ; finalement, il utilise le premier nom restant. En outre, si les déchets de tête contiennent une ligne [b]Prereq: , patch[/b] extrait le premier mot de la ligne de prérequis (normalement un numéro de version) et examine le fichier original pour voir si ce mot peut être trouvé. Si ce n'est pas le cas, [b]patch[/b] demande une confirmation avant de procéder. Le résultat de tout ceci est que vous devriez pouvoir faire, alors que vous vous trouvez dans une interface de news (NdT : nouvelles Usenet), quelque chose du genre : .Sp [b]\|[/b] patch -d /usr/src/local/blurfl .Sp et patcher un fichier du répertoire [b]blurfl[/b] directement à partir de l'article contenant le patch. Si le fichier patch contient plus d'un patch, [b]patch[/b] essaie d'appliquer chacun d'entre eux comme s'ils provenaient de fichiers patchs différents. Cela signifie, entre autres choses, que l'on suppose que le nom du fichier à patcher doit être déterminé pour chaque listing de diff, et que les déchets précédant chaque listing de diff contiennent des choses intéressantes telles que les noms de fichiers et le niveau de révision, comme mentionné précédemment. [size=18] [b]Options[/b] [/size] [table][row][col]    [/col][col][b][/b]-b ou [b][/b]=backup Créer des fichiers de sauvegarde, c.-à-d. que lors du patchage d'un fichier, le fichier original est renommé ou copié au lieu d'être supprimé. Lors de la sauvegarde d'un fichier qui n'existe pas, un fichier de sauvegarde vide, non lisible, est créé comme substitut pour représenter le fichier non existant. Voyez l'option [b]-V[/b] ou [b]=version-control[/b] pour les détails sur la façon dont on détermine le nom des fichiers de sauvegarde.[/col][/row][/table] [b]=backup-if-mismatch[/b] [table][row][col]    [/col][col]Sauvegarder un fichier si le patch ne correspond pas exactement au fichier et que les sauvegardes ne sont normalement pas requises. C'est le comportement par défaut à moins que [b]patch[/b] ne se conforme à s-1POSIXs0.[/col][/row][/table] [b]=no-backup-if-mismatch[/b] [table][row][col]    [/col][col]Ne pas sauvegarder un fichier si le patch ne correspond pas exactement au fichier, et si les sauvegardes ne sont normalement pas requises. C'est le comportement par défaut si [b]patch[/b] se conforme à s-1POSIXs0.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-B [i]préf[/i] or [b][/b]=prefix=[i]préf[/i] Le préfixe [i]préf[/i] d'un nom de fichier lors de la génération de son nom de fichier de sauvegarde simple. Par exemple, avec [b]-B /junk/ ,[/b] le nom de fichier de sauvegarde simple pour [b]src/patch/util.c[/b] est [b]/junk/src/patch/util.c .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]=binary Lire et écrire tous les fichiers dans le mode binaire, sauf pour la sortie standard et [b]/dev/tty .[/b] Cette option n'a pas d'effet sur les systèmes conformes à s-1POSIXs0. Sur les systèmes comme s-1DOSs0 où cette option a un effet, le patch devrait être généré par un [b]diff -a =binary .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-c ou [b][/b]=context Interpréter le fichier patch en tant que diff contextuel ordinaire.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-d [i]rép[/i] ou [b][/b]=directory=[i]rép[/i] Se rendre immédiatement dans le répertoire [b]rép ,[/b] avant de faire quoi que ce soit d'autre.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-D [i]define[/i] ou [b][/b]=ifdef=[i]define[/i] Utiliser la construction [b]#ifdef ... #endif[/b] pour marquer les changements, avec [i]define[/i] comme symbole de différenciation.[/col][/row][/table] [b]=dry-run[/b] [table][row][col]    [/col][col]Afficher les résultats de l'application des patchs sans réellement modifier le moindre fichier.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-e ou [b][/b]=ed Interpréter le fichier patch comme un script [b]ed .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-E ou [b][/b]=remove-empty-files Supprimer les fichiers de sortie vides après que les patchs aient été appliqués. Cette option n'est normalement pas nécessaire, car [b]patch[/b] peut examiner les horodates dans l'en-tête pour déterminer si un fichier devrait exister après le patchage. Néanmoins, si l'entrée n'est pas un diff contextuel ou si [b]patch[/b] se conforme à s-1POSIXs0, [b]patch[/b] ne supprime pas les fichiers patchés vides à moins que cette option ne soit donnée. Quand [b]patch[/b] supprime un fichier, il essaie également de supprimer tout répertoire ancêtre vide.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-f ou [b][/b]=force Supposer que l'utilisateur sait exactement ce qu'il fait, et ne poser aucune question. Passer les patchs dont les en-têtes ne disent pas quel fichier il faut patcher, patcher les fichiers même s'ils ont la mauvaise version dans la ligne [b]Prereq:&[/b] du patch, et supposer que les patchs ne sont pas renversés même s'il semble que cela soit le cas. Cette option ne supprime pas les commentaires ; utilisez [b]-s[/b] pour cela.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-F [i]nombre[/i] ou [b][/b]=fuzz=[i]nombre[/i] Fixer le facteur de bruit maximum. Cette option ne s'applique qu'aux diffs qui ont du contexte, et indique à [b]patch[/b] d'ignorer jusqu'à [i]nombre[/i] lignes lorsqu'il recherche des endroits où installer un composant. Notez qu'un facteur de bruit plus grand augmente la probabilité d'un patch défectueux. Le facteur de bruit par défaut est 2, et ne peut être fixé à plus que le nombre de lignes de contexte du diff contextuel (généralement 3).[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-g [i]nombre[/i] ou [b][/b]=get=[i]nombre[/i] Cette option contrôle les actions de [b]patch[/b] quand un fichier est contrôlé par s-1RCSs0 ou s-1SCCSs0, et n'existe pas ou est accessible en lecture seule et correspond à la version par défaut, ou quand un fichier est sous le contrôle de ClearCase et n'existe pas. Si [i]nombre[/i] est positif, [b]patch[/b] obtient le fichier (ou l'extrait) à partir du système de contrôle de révisions ; s'il est nul, [b]patch[/b] ignore s-1RCSs0, ClearCase et s-1SCCSs0 et n'obtient pas le fichier ; s'il est négatif, [b]patch[/b] 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 [b]PATCH_GET[/b] si elle est définie ; si ce n'est pas le cas, la valeur par défaut est zéro si [b]patch[/b] se conforme à s-1POSIXs0, ou négative sinon.[/col][/row][/table] [b]=help[/b] [table][row][col]    [/col][col]Afficher un résumé des options et se terminer.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-i [i]fichier-patch[/i] ou [b][/b]=input=[i]fichier-patch[/i] Lire le patch à partir de [b]fichier-patch .[/b] Si le [i]fichier-patch[/i] est [b][/b]-, lire depuis l'entrée standard (comportement par défaut).[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-l ou [b][/b]=ignore-whitespace Reconnaître lâchement les motifs, au cas où des tabulations ou des espaces aient été altérés dans vos fichiers. Une séquence d'un ou de plusieurs blancs dans le fichier patch correspond à n'importe quelle séquence du fichier original, et les séquences de blancs à la fin des lignes sont ignorées. Les caractères normaux doivent toujours correspondre exactement. Chaque ligne de contexte doit correspondre exactement à une ligne du fichier original.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-n ou [b][/b]=normal Interpréter le fichier patch en tant que diff normal.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-N ou [b][/b]=forward Ignorer les patchs qui semblent avoir été renversés ou déjà appliqués. Voyez également [b]-R .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-o [i]fichier-sortie[/i] ou [b][/b]=output=[i]fichier-sortie[/i] Envoyer la sortie dans [i]fichier-sortie[/i] au lieu de patcher les fichiers sur place.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-p[i]nombre[/i] ou [b][/b]=strip[b]=[/b][i]nombre[/i] Enlever le plus petit préfixe contenant [i]nombre[/i] slashs de la tête de chaque nom de fichier trouvé dans le fichier patch. Une séquence d'un ou de plusieurs slashs adjacents compte pour un slash unique. Cela contrôle la façon dont les noms trouvés dans le fichier patch sont traités, au cas où vous conserveriez vos fichiers dans un répertoire différent de celui qui a envoyé le patch. Par exemple, en supposant que le nom du fichier dans le fichier patch était .Sp [b]/u/howard/src/blurfl/blurfl.c[/b] .Sp spécifier [b]-p0[/b] donne le nom de fichier entier non modifié, [b]-p1[/b] donne .Sp [b]u/howard/src/blurfl/blurfl.c[/b] .Sp sans le slash de tête, [b]-p4[/b] donne .Sp [b]blurfl/blurfl.c[/b] .Sp et ne pas spécifier de [b]-p[/b] du tout vous donne [b]blurfl.c[/b]. Ce que vous obtenez finalement est recherché soit dans le répertoire courant, soit dans le répertoire spécifié par l'option [b]-d .[/b][/col][/row][/table] [b]=posix[/b] [table][row][col]    [/col][col]Se conformer plus strictement au standard s-1POSIXs0, comme suit :[table][row][col]    [/col][col][/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Opter pour le premier fichier existant à partir de la liste (ancien, nouveau, index) quand on devine les noms de fichiers à partir des en-têtes diff.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Ne pas supprimer les fichiers vides après le patchage.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Ne pas demander s'il faut obtenir les fichiers depuis s-1RCSs0, ClearCase ou s-1SCCSs0.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Requérir que toutes les options précèdent les fichiers sur la ligne de commandes.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Ne pas sauvegarder les fichiers quand il y a une discordance.[/col][/row][/table][/col][/row][/table] [b][i]=quoting-style= mot[/i][/b] [table][row][col]    [/col][col]Utiliser le style [i]mot[/i] de protection des noms en sortie. Le [i]mot[/i] devrait être un des suivants :[table][row][col]    [/col][col][/col][/row][/table] [b]literal[/b] [table][row][col]    [/col][col]Sortir les noms tels quels.[/col][/row][/table] [b]shell[/b] [table][row][col]    [/col][col]Protéger les noms pour le shell s'ils contiennent des métacaractères du shell ou susciteraient une sortie ambiguë.[/col][/row][/table] [b]shell-always[/b] [table][row][col]    [/col][col]Protéger les noms pour le shell, même s'ils ne devraient normalement pas requérir de protection.[/col][/row][/table] [b]c[/b] [table][row][col]    [/col][col]Protéger les noms comme pour une chaîne de caractères dans le langage C.[/col][/row][/table] [b]escape[/b] [table][row][col]    [/col][col]Protéger comme avec [b]c ,[/b] mais omettre les guillemets entourants.[/col][/row][/table]     Vous pouvez spécifier la valeur par défaut de l'option [b]=quoting-style[/b] avec la variable d'environnement [b]QUOTING_STYLE .[/b] Si cette variable d'environnement n'est pas définie, la valeur par défaut est [b]shell .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-r [i]fichier-rejet[/i] ou [b][/b]=reject-file=[i]fichier-rejet[/i] Placer les rejets dans [i]fichier-rejet[/i] au lieu du fichier [b]&.rej[/b] par défaut.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-R ou [b][/b]=reverse Supposer que ce patch a été créé alors que les anciens et nouveaux fichiers avaient été intervertis. (Oui, j'ai peur que cela se produise occasionnellement, la nature humaine étant ce qu'elle est.) [b]patch[/b] essaie d'intervertir chaque composant avant de l'appliquer. Les rejets apparaissent dans le format « échangé ». L'option [b]-R[/b] ne fonctionne pas avec les scripts [b]ed[/b] car il y a trop peu d'informations pour reconstruire l'opération inverse. .Sp Si le premier composant d'un patch échoue, [b]patch[/b] le renverse pour voir s'il peut être appliqué de cette façon. Si c'est le cas, il vous demande si vous voulez que l'option [b]-R[/b] soit utilisée. Si vous ne le souhaitez pas, le patch continue à être appliqué normalement. (Note : cette méthode ne peut détecter un patch reversé si c'est un diff normal et que la première commande est une concaténation (elle aurait du être un effacement) puisque la concaténation réussit toujours, étant donné qu'un contexte nul convient partout. Heureusement, la plupart des patchs ajoutent ou modifient des lignes plutôt que d'en supprimer, de sorte que la plupart des diffs normaux renversés commencent par un effacement, qui échoue, ce qui déclenche l'heuristique.)[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-s ou [b][/b]=silent ou [b][/b]=quiet Travailler silencieusement, à moins qu'une erreur ne se produise.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-t ou [b][/b]=batch Supprimer les questions comme [b]-f ,[/b] mais employer des suppositions différentes : omettre les patchs dont l'en-tête ne contient pas de noms de fichiers (comme pour [b][/b]-f) ; omettre les patchs pour lesquels le fichier a la mauvaise version pour la ligne [b]Prereq:& ;[/b] et supposer que les patchs sont renversés s'il semble que cela soit le cas.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-T ou [b][/b]=set-time Fixer les dates de dernière modification et de dernier accès des fichiers patchés à partir des horodates contenues dans les en-têtes diff contextuels, en supposant que les en-têtes diff contextuels utilisent l'heure locale. Cette option n'est pas recommandée, car les patchs qui utilisent l'heure locale ne peuvent pas facilement être utilisés par des personnes situées dans d'autres fuseaux horaires, et parce que les horodates utilisant l'heure locale sont ambiguës quand les horloges locales sont retardées lors du passage de l'heure d'été à heure d'hiver. Au lieu d'utiliser cette option, générez des patchs utilisant le temps s-1UTCs0 et utilisez l'option [b]-Z[/b] ou [b]=set-utc[/b] à la place.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-u ou [b][/b]=unified Considérer que le fichier patch est un diff contextuel unifié.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-v ou [b][/b]=version Afficher l'en-tête de révision et le niveau de patchs de [b]patch ,[/b] et se terminer.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-V [i]méthode[/i] ou [b][/b]=version-control=[i]méthode[/i] Utiliser la [i]méthode[/i] pour déterminer le nom des fichiers de sauvegarde. La méthode peut également être fournie via la variable d'environnement [b]PATCH_VERSION_CONTROL[/b] (ou, si elle n'est pas définie, via [b]VERSION_CONTROL ),[/b] qui est surchargée par cette option. Cette méthode n'indique pas si des fichiers de sauvegarde doivent être générés ; elle n'affecte que les noms des fichiers de sauvegarde qui sont créés. .Sp La valeur de [i]méthode[/i] est identique à celle de la variable « version-control » de s-1GNUs0 Emacs : [b]patch[/b] reconnaît également des synonymes plus descriptifs. Les valeurs valides pour [i]méthode[/i] sont (les abréviations uniques sont acceptées) :[table][row][col]    [/col][col][/col][/row][/table] [table][row][col]    [/col][col][b]existing[/b] ou [b]nil[/b] Créer des sauvegardes numérotées des fichiers qui en ont déjà, sinon de simples sauvegardes. C'est le comportement par défaut.[/col][/row][/table] [table][row][col]    [/col][col][b]numbered[/b] ou [b]t[/b] Créer des sauvegardes numérotées. Le nom du fichier de sauvegarde numéroté pour [i]F[/i] est [b][i]F .~ N ~[/i][/b] où [i]N[/i] est le numéro de version.[/col][/row][/table] [table][row][col]    [/col][col][b]simple[/b] ou [b]never[/b] Créer des sauvegardes simples. Les options [b]-B[/b] ou [b]=prefix ,[/b] [b]-Y[/b] ou [b]=basename-prefix ,[/b] et [b]-z[/b] ou [b]=suffix[/b] spécifient le nom du fichier de sauvegarde simple. Si aucune de ces options n'est spécifiée, alors un suffixe de sauvegarde simple est utilisé ; il représente la valeur de la variable d'environnement [b]SIMPLE_BACKUP_SUFFIX[/b] si elle est définie, ou est [b]&.orig[/b] sinon.[/col][/row][/table] Avec les sauvegardes numérotées ou simples, si le nom du fichier de sauvegarde est trop long, le suffixe de sauvegarde [b]~[/b] est utilisé à la place ; si même la concaténation d'un [b]~[/b] rendrait le nom trop long, alors [b]~[/b] remplace le dernier caractère du nom de fichier.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]=verbose Produire des informations supplémentaires sur le travail en cours.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-x [i]nombre[/i] ou [b][/b]=debug=[i]nombre[/i] Spécifier des drapeaux de débogage qui intéressent uniquement les patcheurs de [b]patch .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-Y [i]préf[/i] ou [b][/b]=basename-prefix=[i]préf[/i] Préfixer [i]préf[/i] au nom de base d'un nom de fichier lors de la génération de son nom de fichier de sauvegarde simple. Par exemple, avec [b]-Y .del/ ,[/b] le nom du fichier de sauvegarde simple pour [b]src/patch/util.c[/b] est [b]src/patch/.del/util.c .[/b][/col][/row][/table] [table][row][col]    [/col][col][b][/b]-z [i]suffixe[/i] ou [b][/b]=suffix=[i]suffixe[/i] Utiliser le [i]suffixe[/i] comme suffixe de sauvegarde simple. Par exemple, avec [b]-z - ,[/b] le nom du fichier de sauvegarde simple pour [b]src/patch/util.c[/b] est [b]src/patch/util.c- .[/b] Le suffixe de sauvegarde simple peut également être spécifié via la variable d'environnement [b]SIMPLE_BACKUP_SUFFIX ,[/b] qui est surchargée par cette option.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-Z ou [b][/b]=set-utc Fixer les dates de dernier accès et de dernière modification des fichiers patchés à partir des horodates données dans les en-têtes diff contextuels, en supposant que les en-têtes diff contextuels utilisent le Coordinated Universal Time (temps s-1UTCs0, mieux connu sous le nom de s-1GMTs0). Voyez également l'option [b]-T[/b] ou [b]=set-time .[/b] .Sp Les options [b]-Z[/b] ou [b]=set-utc ,[/b] et [b]-T[/b] ou [b]=set-time[/b] empêchent normalement de fixer une date d'un fichier si la date originale du fichier ne correspond pas à celle donnée dans l'en-tête du patch, ou si son contenu ne correspond pas exactement au patch. Néanmoins, si l'option [b]-f[/b] ou [b]=force[/b] est spécifiée, la date du fichier est tout de même fixée. .Sp À cause des limitations du format de sortie de [b]diff ,[/b] ces options ne peuvent mettre à jour les dates des fichiers dont le contenu n'a pas changé. De plus, si vous utilisez ces options, vous devriez supprimer (p.ex. avec [b]make clean )[/b] tous les fichiers qui dépendent des fichiers patchés, afin que des invocations ultérieures de [b]make[/b] ne soient pas dupées par les dates des fichiers patchés.[/col][/row][/table] [size=18] [b]Environnement[/b] [/size] [b]PATCH_GET[/b] [table][row][col]    [/col][col]Spécifie si [b]patch[/b] doit obtenir les fichiers manquants ou en lecture seule depuis s-1RCSs0, ClearCase ou s-1SCCSs0 par défaut ; voyez l'option [b]-g[/b] ou [b]=get .[/b][/col][/row][/table] [b]POSIXLY_CORRECT[/b] [table][row][col]    [/col][col]Si elle est définie, [b]patch[/b] se conforme plus strictement au standard s-1POSIXs0 par défaut : voyez l'option [b]=posix .[/b][/col][/row][/table] [b]QUOTING_STYLE[/b] [table][row][col]    [/col][col]Valeur par défaut pour l'option [b]=quoting-style .[/b][/col][/row][/table] [b]SIMPLE_BACKUP_SUFFIX[/b] [table][row][col]    [/col][col]Extension à utiliser pour le nom des fichiers de sauvegarde simple au lieu de [b].orig .[/b][/col][/row][/table] [table][row][col]    [/col][col][b]TMPDIR[/b], [b]TMP[/b], [b]TEMP[/b] Répertoire ou placer les fichiers temporaires ; [b]patch[/b] utilise la première variable d'environnement de cette liste qui est définie. Si aucune n'est définie, le répertoire par défaut dépend du système ; il est normalement [b]/tmp[/b] pour les hôtes Unix.[/col][/row][/table] [table][row][col]    [/col][col][b]VERSION_CONTROL[/b] ou [b]PATCH_VERSION_CONTROL[/b] Sélectionne le style de contrôle de version ; voyez l'option [b]-v[/b] ou [b]=version-control .[/b][/col][/row][/table] [size=18] [b]Fichiers[/b] [/size] [b][i]$TMPDIR /p(*[/i][/b] [table][row][col]    [/col][col]fichiers temporaires[/col][/row][/table] [b]/dev/tty[/b] [table][row][col]    [/col][col]terminal de contrôle ; utilisé pour obtenir des réponses aux questions posées à l'utilisateur[/col][/row][/table] [size=18] [b]Voir aussi[/b] [/size] [b]diff (1),[/b] [b]ed (1)[/b] .Sp Marshall T. Rose and Einar A. Stefferud, Proposed Standard for Message Encapsulation, RFC Internet 934 <URL:ftp://ftp.isi.edu/in-notes/rfc934.txt> (1985-01). [size=18] [b]Notes[/b] [/size] Il y a plusieurs choses que vous devriez garder à l'esprit si vous avez l'intention d'émettre des patchs. Créez votre patch de façon systématique. Une bonne méthode est la commande [b][i]diff -Naur ancien/nouveau[/i][/b] où [i]ancien[/i] et [i]nouveau[/i] identifient l'ancien et le nouveau répertoire respectivement. Les noms [i]ancien[/i] et [i]nouveau[/i] ne devraient pas contenir de slashs. Les en-têtes de la commande [b]diff[/b] devraient posséder des dates et des heures dans le Temps Universel en utilisant le format Unix traditionnel, afin que les destinataires du patch puissent utiliser l'option [b]-Z[/b] ou [b]=set-utc .[/b] Voici une commande d'exemple, qui utilise la syntaxe du shell Bourne : .Sp [b]LC_ALL=C[/b] TZ=UTC0 diff -Naur gcc-2.7 gcc-2.8 Indiquez à vos destinataires la façon d'appliquer le patch en leur disant dans quel répertoire ils doivent se rendre, et quelles options de [b]patch[/b] utiliser. La chaîne d'options [b]-Np1[/b] est recommandée. Testez votre procédure en faisant semblant d'être un destinataire et en appliquant votre patch sur une copie des fichiers originaux. Vous pouvez épargner un tas de cheveux blancs aux utilisateurs de votre patch en conservant un fichier [b]patchlevel.h[/b] qui est patché pour incrémenter le niveau de patchs en tant que permier diff du fichier patch que vous envoyez. Si vous placez une ligne [b]Prereq:&[/b] dans le patch, il ne vous laissera pas les appliquer dans le désordre sans avertissement. Vous pouvez créer un fichier en envoyant un diff qui compare [b]/dev/null[/b] ou un fichier vide daté de l'Epoch (01/01/1970 00:00:00 s-1UTCs0) avec le fichier que vous voulez créer. Cela ne fonctionne que si le fichier que vous voulez 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 à effacer avec un fichier vide daté de l'Epoch. Le fichier sera supprimé à moins que [b]patch[/b] ne se conforme à s-1POSIXs0 et que l'option [b]-E[/b] ou [b]=remove-empty-files[/b] n'est pas donnée. Une manière commode de générer des patchs qui créent ou suppriment des fichiers est d'utiliser l'option [b]-N[/b] ou [b]=new-file[/b] du [b]diff[/b] s-1GNUs0. Si le destinataire est censé utiliser l'option [b][/b]-p [b]N ,[/b] n'envoyez pas de sortie ressemblant à ceci : .Sp .ft B .ne 3 diff -Naur v2.0.29/prog/README prog/README [b][/b] -^-^- v2.0.29/prog/README Mon Mar 10 15:13:12 1997 [b][/b] +^+^+ prog/README Mon Mar 17 14:58:22 1997 .ft .Sp car les deux noms de fichiers ont un nombre différent de slashs, et différentes versions de [b]patch[/b] interprètent les noms de fichiers différemment. Pour éviter une confusion, envoyez plutôt une sortie qui ressemble à ceci : .Sp .ft B .ne 3 diff -Naur v2.0.29/prog/README v2.0.30/prog/README [b][/b] -^-^- v2.0.29/prog/README Mon Mar 10 15:13:12 1997 [b][/b] +^+^+ v2.0.30/prog/README Mon Mar 17 14:58:22 1997 .ft .Sp Évitez d'envoyer des patchs qui comparent des noms de fichiers de sauvegarde comme [b]README.orig ,[/b] car cela pourrait embrouiller [b]patch[/b] qui patcherait alors un fichier de sauvegarde au lieu du fichier réel. Au lieu de cela, envoyez des patchs qui comparent les mêmes noms de base de fichiers dans des répertoires différents, comme p.ex. [b]old/README[/b] et [b]new/README .[/b] Prenez bien soin de ne pas envoyer de patchs renversés, car les gens pourraient se demander s'ils n'ont pas déjà appliqué le patch. Évitez si possible que votre patch modifie des fichiers dérivés (p.ex. le fichier [b]configure[/b] quand il y a une ligne [b]configure: configure.in[/b] dans votre makefile), car le destinataire devrait de toute façon avoir la possibilité de régénérer les fichiers dérivés. Si vous devez envoyez des diffs de fichiers dérivés, générez-les en utilisant le temps s-1UTCs0, faites en sorte que les destinataires appliquent le patch avec l'option [b]-Z[/b] ou [b]=set-utc ,[/b] et faites-leur supprimer les fichiers non patchés qui dépendent des fichiers patchés (p.ex. avec [b]make clean ).[/b] Bien que vous puissiez vous en sortir en plaçant 582 listings de diff dans un fichier, il peut être plus judicieux de grouper les patchs apparentés dans des fichiers séparés au cas où quelque chose tourne mal. [size=18] [b]Diagnostiques[/b] [/size] Les diagnostics indiquent généralement que [b]patch[/b] n'a pas pu analyser votre fichier patch. Si l'option [b]=verbose[/b] est donnée, le message [b]Hmm...&[/b] indique qu'il reste du texte non traité dans le fichier patch et que [b]patch[/b] essaie de deviner s'il contient un patch et, le cas échéant, de quel type il s'agit. Le code de retour de [b]patch[/b] est 0 si tous les composants ont été appliqués avec succès, 1 si certains d'entre eux n'ont pas pu être appliqués, et 2 en cas de problème plus sérieux. Lors de l'application d'un groupe de patchs dans une boucle, il vous incombe de vérifier ce code de retour afin de ne pas appliquer ultérieurement un patch sur un fichier partiellement patché. [size=18] [b]Avertissements[/b] [/size] Les diffs contextuels ne peuvent pas représenter fiablement la création ou l'effacement de fichiers vides, de répertoires vides, ou de fichiers spéciaux comme les liens symboliques. Ils ne peuvent pas non plus représenter les métadonnées de fichiers comme la propriété, les permissions, ou si un fichier est un lien matériel vers un autre. Si des changements tels que ceux-ci sont également requis, des instructions séparées (p.ex. dans un script shell) permettant de les mettre en ½uvre devraient accompagner le patch. [b]patch[/b] ne peut dire si les numéros de ligne sont désactivés dans un script [b]ed ,[/b] et ne peut détecter les mauvais numéros de lignes dans un diff normal que lorsqu'il détecte un changement ou un effacement. Un diff contextuel utilisant un facteur de bruit de 3 peut avoir le même problème. En attendant qu'une interface interactive appropriée soit ajoutée, vous devriez probablement utiliser un diff contextuel dans ces cas pour voir si les changements ont du sens. Bien sûr, une compilation sans erreur est un bon indicateur que le patch a fonctionné, mais pas toujours. [b]patch[/b] produit habituellement les résultats escomptés, même quand il doit deviner beaucoup de choses. Néanmoins, des résultats corrects ne sont garantis que lorsque le patch est appliqué sur exactement la même version du fichier que celle à partir de laquelle le patch a été généré. [size=18] [b]Compatibilité[/b] [/size] Le standard s-1POSIXs0 spécifie un comportement qui diffère du comportement traditionnel de [b]patch .[/b] Vous devriez être conscient de ces différences si vous devez interopérer avec [b]patch[/b] version 2.1 et précédentes, qui ne se conforment pas à s-1POSIXs0. [b] (bu[/b] [table][row][col]    [/col][col]Dans le [b]patch[/b] traditionnel, l'opérande de l'option [b]-p[/b] était optionnel, et un [b]-p[/b] nu était équivalent à [b]-p0 .[/b] L'option [b]-p[/b] requiert maintenant un opérande, et [b]-p 0[/b] est actuellement équivalent à [b]-p0 .[/b] Pour une compatibilité maximale, utilisez des options comme [b]-p0[/b] et [b]-p1 .[/b] .Sp De plus, le [b]patch[/b] traditionnel comptait simplement les slashs lors de l'enlèvement des préfixes de chemin ; [b]patch[/b] compte maintenant les composants du nom de chemin, c.-à-d. qu'une séquence d'un ou de plusieurs slashs adjacents compte désormais pour un seul slash. Pour une portabilité maximale, évitez d'envoyer des patchs contenant [b]//[/b] dans les noms de fichiers.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Dans le [b]patch[/b] traditionnel, les sauvegardes étaient activées par défaut. Ce comportement est maintenant activé par l'option [b]-b[/b] ou [b]=backup .[/b] .Sp Inversement, dans le [b]patch[/b] s-1POSIXs0, les sauvegardes n'étaient jamais créées, même en cas de discordance. Dans le [b]patch[/b] s-1GNUs0, ce comportement est activé par l'option [b]=no-backup-if-mismatch ,[/b] ou en se conformant à s-1POSIXs0 avec l'option [b]*=posix ,[/b] ou encore en définissant la variable d'environnement [b]POSIXLY_CORRECT .[/b] .Sp L'option [b][i]-b suffixe[/i][/b] du [b]patch[/b] traditionnel est équivalente aux options [b][i]-b -z suffixe[/i][/b] du [b]patch[/b] s-1GNUs0.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Le [b]patch[/b] traditionnel utilisait une méthode compliquée (et documentée de façon incomplète) pour deviner le nom du fichier à patcher à partir de l'en-tête du patch. Cette méthode ne se conformait pas à s-1POSIXs0, et comportait quelques pièges. À l'heure actuelle, [b]patch[/b] utilise une méthode différente, aussi compliquée (mais mieux documentée) qui se conforme optionnellement à s-1POSIXs0 ; nous espérons qu'elle comporte moins de pièges. Les deux méthodes sont compatibles si les noms de fichiers de l'en-tête du diff contextuel et la ligne [b]Index:&[/b] sont totalement identiques après la phase de suppression de préfixe. Votre patch est normalement compatible si les noms de fichiers de tous les en-têtes contiennent tous le même nombre de slashs.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Quand le [b]patch[/b] traditionnel posait une question à l'utilisateur, il envoyait la question sur la sortie d'erreur standard, et recherchait une réponse dans le premier fichier de la liste suivante qui était un terminal : l'erreur standard, la sortie standard, [b]/dev/tty ,[/b] et l'entrée standard. À l'heure actuelle, [b]patch[/b] envoie ses questions sur la sortie standard et obtient les réponses à partir de [b]/dev/tty .[/b] Certaines réponses par défaut ont été modifiées afin que [b]patch[/b] n'entre pas dans une boucle infinie quand il utilise les réponses par défaut.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Le [b]patch[/b] traditionnel se terminait avec un code de retour qui comptabilisait le nombre de mauvais composants, ou avec le code de retour 1 en cas de problème sérieux. À l'heure actuelle, [b]patch[/b] se termine avec un code de retour de 1 si certains composants ont échoué, ou 2 en cas de problème sérieux.[/col][/row][/table] [b] (bu[/b] [table][row][col]    [/col][col]Limitez-vous aux options suivantes quand vous envoyez des instructions destinées à être exécutées par quelqu'un exécutant le [b]patch[/b] s-1GNUs0, le [b]patch[/b] traditionnel, ou un [b]patch[/b] qui se conforme à s-1POSIXs0. Les espaces sont significatives dans la liste suivante, et les opérandes sont requis. .Sp .nf .in +3 .ne 11 [b]-c[/b] [b][i]-d rép[/i][/b] [b][i]-D define[/i][/b] [b]-e[/b] [b]-l[/b] [b]-n[/b] [b]-N[/b] [b][i]-o fichier-sortie[/i][/b] [b][i]-p nombre[/i][/b] [b]-R[/b] [b][i]-r fichier-rejet[/i][/b] .in .fi[/col][/row][/table] [size=18] [b]Bugs[/b] [/size] Rapportez s.v.p. les bogues via courrier électronique à [b]<bug-gnu-utils@gnu.org> .[/b] [b]patch[/b] pourrait être plus intelligent en ce qui concerne les correspondances partielles, les décalages excessifs et l'inversion de code, mais cela requerrait une passe supplémentaire. Si le code a été dupliqué (par exemple avec [b]#ifdef[/b] ANCIENCODE ... [b]#else[/b] ... #endif), [b]patch[/b] est incapable de patcher les deux versions et, si jamais il fonctionne, patchera probablement le mauvais, et vous dira qu'il a réussi à démarrer. Si vous appliquez un patch que vous avez déjà appliqué, [b]patch[/b] pense que c'est un patch renversé et offre la possibilité de dés-appliquer le patch. Cela pourrait être interprété comme une fonctionnalité. [size=18] [b]Copyright[/b] [/size] Copyright .if t (co 1984, 1985, 1986, 1988 Larry Wall. [b][/b] Copyright .if t (co 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc. L'autorisation est donnée de créer et de distribuer des copies textuelles de ce manuel, à condition que la notice de copyright et la notice de permission soient préservées dans toutes les copies. L'autorisation est donnée de copier et distribuer des versions modifiées de ce manuel sous les conditions de copie textuelle, à condition que l'entièreté du travail dérivé résultant soit distribuée sous les termes d'une autorisation identique à celle-ci. L'autorisation est donnée de copier et distribuer des traductions de ce manuel dans n'importe quelle autre langue, sous les conditions ci-dessus pour les versions modifiées, sauf que cette notice de permission peut être incluse dans des traductions approuvées par les détenteurs du copyright au lieu de l'anglais originel. [size=18] [b]Auteurs[/b] [/size] Larry Wall a écrit la version originale de [b]patch .[/b] Paul Eggert a supprimé les limites arbitraires de [b]patch ,[/b] a ajouté le support des fichiers binaires, la spécification des dates du fichier, et l'effacement de fichiers, et l'a fait mieux se conformer à s-1POSIXs0. Les autres contributeurs incluent Wayne Davison, qui a ajouté le support du diff unifié, et David MacKenzie, qui a ajouté la prise en charge de la configuration et de la sauvegarde. [size=18] [b]Traduction[/b] [/size] Frédéric Delanoy <[i]delanoy_f[/i] at yahoo.com>, 2002.
Fichier