НАЗВА ¶

patch - застосує файл diff до оригіналу

КОРОТКИЙ ОГЛЯД ¶

patch [ опції ] [оригінал [ латка ]]

але частіше лишень:

patch -p номер < латка

ОПИС ¶

patch візьме файл латку , що містить список відмінностей, створений програмою diff(1) (ми будемо іноді називати цей список як diff), і вжиє ці відмінності до одного або більше оригінальних файлів, створюючи залатані версії файлів. Як правило, залатані версії замінюють оригінали. Резервні копії також можливі; дивіться опції -b або --backup . Назви файлів, що належить залатати, беруться з файлу-латки, але якщо це всього лиш один файл, його можна вказати на командному рядку як оригінал .

Під час запуску, patch намагається визначити тип списку diff, хіба ця поведінка переважена однією з опцій: -c ( --context ), -e ( -ed ), -n ( --normal ) або -u ( --unified ). Контекстуальні відмінності (old-style, new-style, і unified) і звичні відмінності patch вжиє без сторонньої допомоги, тоді як відмінності ed будуть передані через конвеєр редактору ed(1).

patch намагається пропустити будь-яке передуюче сміття, застосувати латку і пропустити кінцеве сміття. Таким чином, ви можете подати patch якусь статтю або послання електронної пошти, що містить список diff серед тексту, і латка повинна спрацювати. Якщо цілий diff зсунуто вправо, або якщо зміст diff містить рядки з закінченням CRLF, або герметизовано (інскапульовано) один або декілька разів, через додання - до рядків що починаються з -, як вказано у RFC 934, це також буде враховано.

У контекстних diff і, в меншій ступені у звичайних diff, patch може вгадати, коли номер рядка, вказаний у латці, не є вірним і намагається знайти правильне місце, де можна вжити кожний кусок латки. При першій спробі, береться номер рядка, вказаний для куска у латці, плюс або мінус зсув, який застосовувався для аплікації попереднього куска. Якщо місце виявиться невдалим, patch сканує в обох напрямках, вперед і назад, на предмет рядків, що співпадають з тими, що вказано в куску. Спочатку patch шукає місця, де всі рядки контексту співпадають. Якщо такого не знайдено, і це контекстний diff, максимальний фактор похибки встановлено до 1 або більше, тоді наступне сканування матиме місце, ігноруючи перший і останній рядок контексту. Якщо це також зазнає невдачі, і максимальний фактор похибки встановлено до 2 або більше, перші два й останні два рядка контексту буде ігноровано і додаткове сканування матиме місце. (Фактор похибки за узгодженістю дорівнює 2).

У випадку, якщо patch не може знайти місця застосування куска латки, він збереже цей кусок у файл відкинутих латок, назва якого буде співпадати з назвою вихідного файлу, плюс суфікс .rej або # , якщо .rej створить файл із занадто довгою назвою (якщо навіть # неможливо додати, тоді ґратка замінить останній знак назви файлу). (Кусок, що відкинуто, зберігається у формі контекстуального diff, незалежно від того яка форма вживалась у файлі латки. Якщо латка містила звичайний diff, багато з контексту анулюється.)

Номер рядків кусків у файлі відкинутих латок може відрізнятись від аналогічних з самої латки: вони відображають приблизне місцезнаходження, яке на думку patch не вдалося залатати у новому файлі (вже після дії patch ) а не у старому. По мірі того, як кожний кусок оброблено, ви отримаєте інформацію, котрий з них зазнав невдачі і якому саме рядку (нового файлу), patch гадає, належить цей кусок.

Якщо кусок розміщено в обробленому тексті у відмінному місці від того що вказано у файлі-латці, ви також отримаєте інформацію про розмір зміщення. Одне велике зміщення може означати, що кусок розміщено у хибному місці. Важ також поінформують про фактор похибки, який використовувався для співпадань. Якщо була вказана опція --verbose , ви додатково отримаєте інформацію про те, які з кусків співпали точно.

Якщо жодного файлу оригіналу не було вказано на командному рядку, patch спробує вгадати з файлу латки, який саме файл редагувати, керуючись наступними правилами:

* Якщо заголовок вказує що це контекстний diff, patch візьме назви старого і нового файлів з заголовку. Назву буде ігноровано, якщо вона не містить достатньо слешів щоб вдовольнити опції -p число або --strip=число. Назва /dev/null також ігнорується.

* Якщо присутній рядок Index: серед передуючого тексту і якщо нова і стара назва файлу відсутні або patch узгоджено з POSIX, тоді patch візьме назву з рядка Index: .
* Для наступних правил, можливі назви файлів вважаються упорядкованими (старий, новий, індекс), незалежно від того як вони з'являються у заголовку.

Потім patch вибирає назву файлу з-поміж списку кандидатів наступним чином:

* Якщо деякі з названих файлів існують, patch вибере першу назву, якщо встановлена узгодженість з POSIX, і найкращу назву у протилежному випадку.

* Якщо patch не ігнорує RCS, ClearCase і SCCS (дивіться опції -g число або --get=число), і жодного з вказаних файлів не існує, зате знайдено RCS, ClearCase, або SCCS master, patch вибере перший вказаний файл з RCS, ClearCase, або SCCS master.

* Якщо вказаного файлу не було знайдено, так само як RCS, ClearCase або SCCS master, patch не узгоджено з POSIX і латка, схоже, створить новий файл, patch вибере найкращу назву, яка вимагає створення найменшої кількості тек.

* Якщо жодної назви файлу не видобуто завдяки вище наведеної евристики, patch спитає вас назву файлу.

Для того щоб вибрати найкращу назву зі списку назв файлів, patch спочатку розглядає всі назви з найменшою кількістю складових, серед них вибирає ті, що мають найкоротшу базову назву (basename), серед базових назв також вибирається найкоротша і, накінець, вибір падає першу з назв серед тих що залишились.

Додатково, якщо сміття напочатку латки містить рядок Prereg: , patch прочитає перше слово з цього рядка необхідних умов (як правило, номер версії) і перевірить оригінальний файл, щоб виявити чи містить він це слово. Якщо ні, patch спитає підтвердження перед тим як діяти.

Як результат вищесказаного, ви можете, знаходячись у переглядачі новин скажімо, видати команду на зразок:

 | patch -d /usr/src/local/blurfl

Якщо файл латки містить більше ніж одну латку, patch намагатиметься вжити кожну з них так, ніби вони надійшли з різних файлів латок. Це також означає, що назву оригіналу для латання доведеться вгадати для кожного списку diff і, що непотріб перед кожним списком diff містить цікаві речі, такі як назви файлів і рівень модифікації, як було вказано вище.

КЛЮЧІ ¶

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

u/howard/src/blurfl/blurfl.c

blurfl/blurfl.c

СЕРЕДОВИЩE¶

Наступні змінні середовища впливатимуть на роботу patch:

PATCH_GET

Вказує чи повинен patch видобувати відсутні або тільки для читання файли з RCS, ClearCase або SCCS за замовчуванням. Дивіться також опцію -g або --get.

POSIXLY_CORRECT

Якщо її встановлено, patch слідує точніше стандарту POSIX за замовчуванням. Дивіться також опцію --posix.

QUOTING_STYLE

Значення за замовчуванням для опції --quoting-style.Спосіб залапковування і екранації.

SIMPLE_BACKUP_SUFFIX

Суфікс, що додається до звичайних резервних копій, замість .orig.

TMPDIR , TMP , TEMP

Каталог для розміщення тимчасових файлів. patch використовує першу ж встановлену змінну середовища з цього списку. Якщо жодної не було встановлено, каталог тимчасових файлів є системозалежним; звичайно, це /tmp у Юніксах.

ФАЙЛИ ¶

ДИВІТЬСЯ ТАКОЖ ¶

diff(1), ed(1)

Запропонований Marshall T. Rose і Einar A. Stefferud, Стандарт Герметизації Повідомлень. Internet RFC 934 <ftp://ftp.isi.edu/in-notes/rfc934.txt> (1985-01).

ПРИМІТКА ДЛЯ ВІДПРАВНИКІВ ЛАTOK¶

Існує декілька речей, які варто мати на увазі перед тим як відправляти латки куди інде.

Створюйте власні латки, дотримуючись певної системи. Хорошою методою вважається команда diff -Naur стара нова, де стара і нова вказують на відповідні стару і нову теку (до змін і після змін). Назви старої і нової не повинні містити жодних слешів. Заголовки, генеровані командою diff, повинні містити дату і час у UTC і традиційному форматі Юнікс, тож отримувач латки в змозі буде використати опції -Z або --set-utc. Ось приклад, використовуючи синтаксис оболонки Bash:

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

Ви можете запобігти багатьом нещастям, якщо зберігатимете файл patchlevel.h, який лататиметься для збільшення рівня латки як перший diff у файлі латки, яку ви відправите. Також, якщо добавити рядок Prereq: до латки, це не дозволить застосувати латку в неправильній послідовності без звісток про помилки.

Ви можете створювати нові файли якщо відішлете diff, що порівнює /dev/null або порожній файл, датований Epoch (1970-01-01 00:00:00 UTC) до файлу, який ви хочете створити. Це спрацює лише у тому випадку, якщо файлу, який ви хочете створити, ще не існує у каталозі призначення. І навпаки, ви можете видалити файл, якщо пошлете контекстний diff, який порівнює файл до вилучення з порожнім файлом датованим Epoch. Файл буде видалено, хіба patch слідує POSIX і не були вказані опції -E або --remove-empty-files. Легшим способом створення і видалення файлів є використання прапорців -N та --new-file, які надає GNU diff.

Якщо від отримувача очікується вживання опції -pN, не посилайте латок, що виглядають як:

 diff -Naur v2.0.29/prog/README prog/README


 --- v2.0.29/prog/README   Mon Mar 10 15:13:12 1997


 +++ prog/README   Mon Mar 17 14:58:22 1997

 diff -Naur v2.0.29/prog/README v2.0.30/prog/README


 --- v2.0.29/prog/README   Mon Mar 10 15:13:12 1997


 +++ v2.0.30/prog/README   Mon Mar 17 14:58:22 1997

Будьте обережними не посилати обернуті латки, оскільки це заставляє людей серйозно задуматись, чи вони застосували вже латку, чи ні.

Намагайтесь, щоб ваші латки не змінювали похідні файли (наприклад, файл configure, маючи рядок configure: configure.in у вашому makefile), оскільки отримувач має змогу генерувати похідні файли самостійно. Якщо ви вимушені змінювати похідні файли, створюйте diff, використовуючи UTC і вкажіть користувачам вжити -Z або --set-utc опції, так само як видалити будь-які незалатані файли, що залежать від латаних (наприклад, командою make clean).

Навіть якщо ви можете помістити 582 різних diff у один файл, буде розумнішим розділити споріднені латки у окремі файли у випадку як щось піде не так як заплановано.

ДІАГНОСТИКА ¶

Діагностичні повідомлення, як правило, вказують на те, що path не в змозі був обробити або зрозуміти вашу латку.

Якщо надана опція --verbose , повідомлення, що починається з Hmm... вказує на те, що у тексті латки існує ще не оброблений текст і що patch намагається вгадати, чи це дійсно латка і якщо так, то яка саме.

Статус виходу patch буде 0, якщо всі відрізки вдалося застосувати, 1 - якщо ні і 2 у випадку серйозніших несправностей. Під час застосування латок у циклі, patch підказує вам перевірити статус виходу, тож вам не доведеться пізніше вжити іншу латку на частково залатаному файлі.

ЗАСТЕРЕЖЕННЯ ¶

Контекстуальні diff не надто надійні для створення або вилучення порожніх файлів, порожніх каталогів чи спеціальних файлів, таких як символічні посилання, наприклад. Так само вони не справляються зі змінами метаданих файлів, таких як належність, дозволи і чи є файл жорстким посиланням на інший файл. Якщо вищевказані зміни також необхідні, тоді варто супроводжувати латку ще й оболонковим скриптом для цього.

patch не в змозі розрізнити чи рядки зміщені у випадку скрипту ed , так само може виявити помилковий порядок рядків у звичайному diff лише якщо знайде зміни у тексті або вилучення. Контекстуальний diff зi степінню неточності 3 може потерпувати від того самого. До тих пір, доки не буде втілено більш-менш задовільний інтерактивний інтерфейс, намагайтесь вживати контекстуальні diff у таких випадках, щоб впевнитись, що зміни були чинними. Звичайно, компіляція без помилок є досить непоганим покажчиком того, що латка спрацювала, але не завжди.

patch , загалом, видає вірні результати, навіть якщо йому доводиться здійснювати багато вгадувань. Тим не менш, результат гарантовано правильний лише у випадку, коли латку наставлено на точно ту саму версію файлу, з якої саму латку було створено.

ПИТАННЯ СУМІСНОСТІ ¶

Стандарт POSIX описує поведінку, яка відрізняється від традиційного поводження patch . Ви повинні зважати на ці відмінності, якщо вимушені використовувати patch версії 2.1 або старшої, які не відповідають стандартові POSIX.

* У традиційному patch , аргументи опції -p не були обов'язковими і просто -p дорівнювало -p0 . На сьогодення, опція -p вимагає аргументу і -p 0 є еквівалентним -p0 . Для покращеної сумісності, використовуйте ці опції як -p0 і -p1. Також традиційний patch просто рахував слеші під час видалення префіксу назв шляхів; patch тепер вираховує складові назв шляхів. Тобто, послідовність з одного або більше суміжних слешів вважається одним слешом. Для сумісності зі старими версіями, уникайте використання латок, що містять // у назвах файлів.

* У традиційному patch , резервне копіювання було ввімкнене за замовчуванням. Тепер потрібно добавляти -b або --backup опції. І, навпаки, у patch , що слідує POSIX, резервні копії ніколи не робляться, навіть якщо відбулося неспівпадання. У patch від GNU такого поводження можна добились лише опцією --no-backup-if-mismatch або ввімкнувши сумісність з POSIX опцією --posix або через встановлення змінної середовища POSIXLY_CORRECT. Опція -b суфікс традиційного patch є еквівалентною опції -b -z суфікс GNU patch .

* Традиційний patch використовував складну (і не досить документовану) методу вгадування назв файлів для обробки з заголовку латки. Ця метода не узгоджувалась з POSIX і містила декілька пасток для незнаючих. Тепер patch використовує відмінну, так само складну (але документовану) методу, яка, якщо бажано, може бути POSIX-сумісною. Ми сподіваємось, вона містить менше пасток. Ці дві методи сумісні у випадку, якщо назви файлів у заголовку контекстного diff і рядку Index: співпадають після вилучення префіксу. Ваша латка, як правило, сумісна, якщо назви файлів у кожному заголовку містять рівне число слешів.

* Під час задання питань користувачеві, традиційний patch посилав питання до пристрою стандартної помилки і очікував надходження відповіді з одного з: стандартної помилки, стандартного виводу, /dev/tty і стандартного вводу. Тепер patch посилає питання на стандартний вивід і очікує відповіді на /dev/tty . Деякі відповіді за замовчуванням помінялись, тож patch не опиняється у нескінченному циклі після використання стандартної відповіді.

* Статус виходу традиційного patch дорівнював кількості поганих кусків, або 1, у випадку серйознішої помилки. Тепер patch виходить із статусом 1, якщо деякі куски не співпали і 2 у випадку важливішої помилки.

* Намагайтесь обмежитись наступними опціями, якщо посилаєте інструкції по застосуванню латки будь-ким, хто використовує GNU patch, традиційний patch або POSIX-сумісний patch. Пробіли є важливими у наступному списку і аргументи обов'язковими:

-c
-d каталог
-D означення
-e
-l
-n
-N
-o вихідний_файл
-p число
-R
-r rejectfile

НЕДОЛІКИ ¶

Будь ласка, доповідайте про помилки на <bug-gnu-utils@gnu.org>.

patch міг би бути розумнішим щодо часткових співпадань, занадто великих зміщень рядків і поміняного місцями коду. Але це забиратиме більше часу.

Якщо код випадково дубльовано (наприклад шляхом #ifdef СТАРИЙ_КОД ... #else ... #endif), patch неспроможний залатати обидві версії, і навіть якщо так, то скоріш за все залатає помилкову. Тож будьте уважними.

Якщо ви застосовує латку, яка все була вжита, patch думає, що це обернута латка, надаючи вам таким чином можливість скасувати останню латку. Це можна розглядати як своєрідна риса програми.

АВТОРСЬКІ ПРАВА ¶

Copyright 1984, 1985, 1986, 1988 Larry Wall. Copyright 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be included in translations approved by the copyright holders instead of in the original English.

---- Переклад: Віталій Цибуляк <vi@uatech.atspace.com>