НАЗВА
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
і залатати теку _blurfl _ безпосередньо з допису у новинах.
Якщо файл латки містить більше ніж одну латку, patch намагатиметься вжити кожну з них так, ніби вони надійшли з різних файлів латок. Це також означає, що назву оригіналу для латання доведеться вгадати для кожного списку diff і, що непотріб перед кожним списком diff містить цікаві речі, такі як назви файлів і рівень модифікації, як було вказано вище.
КЛЮЧІ
**-b** або **--backup** | Створює резервні копії. Тобто, під час латання файлу, змінить назву оригіналів або скопіює їх, замість видалити. Якщо оригінального файлу до цього не існувало, буде створено пустий, нечитаємий резервний файл як заповнювач. Подивіться опцію **-V ** або **--version-control** , щоб дізнатися як визначаються імена резервних копій. |
**--backup-if-mismatch** | Створить резервну копію, якщо латка не повністю співпала з файлом і не було вказано робити резервних копій. Це стандартне поводження, хіба patch відповідає POSIX. |
**--no-backup-if-mismatch** | Не створює резервну копію, якщо латка не повністю співпала з файлом і не було вказано робити резервних копій. Це поводження **patch** , узгодженого з POSIX. |
**-B** _префікс_ або **--perfix=**_префікс_ | Добавляє _префікс _ до назви файлу під час створення резервної копії. Наприклад з **-B** _junk_, простою резервною копією для _src/patch/util.c _ буде _/junk/src/patch/util.c_ . |
**--binary** | Читатиме і записуватиме всі файли у бінарному стані, за винятком стандартного виводу і **/dev/tty** . Ця опція не діє на системах, що дотримуються стандарту POSIX і має зміст лише на системах на зразок DOS, де можна вжити **diff -a --binary** . |
**-c** або **--context** | Розглядатиме латку як звичайний контекстний diff. |
**-d** _тека_ або **--directory=**_тека_ | Перейти у _теку_ негайно, перед тим як здійснити щось. |
**-D** _означення_ або **--ifdef=**_означення_ | Використати **#ifdef ... #endif ** конструкцію для позначення змін, з _означенням_ у якості диференційного (розрізнювального) символу. |
**--dry-run** | Вивести лише результат застосування латки, але не латати в дійсності файл. |
**-e** або **--ed** | Розглядати латку як скрипт **ed** . |
**-E** або **--remove-empty-files** | Видалити вихідні файли, якщо вони виявились пустими після вживання латки. Звичайно, ця опція не потрібна, оскільки **patch ** сам може розглянути часові мітки в заголовках, щоб вирішити чи файл повинен існувати після латки. Тим не менш, коли ввід не являється контекстним diff або **patch ** слідує POSIX, порожні файли не видаляються, якщо цієї опції не було вказано. Під час видалення файлу, також відбувається спроба усунути порожні каталоги в яких вони знаходились. |
**-f** або **--force** | Припустити, що користувач знає що робить і не задавати зайвих питань. Пропускати латки, чиї заголовки не вказують який файл залатати; латати файли, навіть якщо вони мають неправильну версію для рядка **Prereq: ** латки; припустити що латки не відбулися у зворотньому напрямку, навіть якщо виглядає на те. Ця опція не пригнічує коментарі, використайте **-s ** для цього. |
**-F** _число_ або **--fuzz=**_число_ | Встановити долю можливої похибки. Ця опція стосується лише diff з доданим контекстом (контекстні diff), і спричиняє до ігнорування певної кількості рядків що не співпадають при пошуку patch місця запису куска. Зауважте, що більший фактор похибки також збільшує ризик невірної латки. Стандартна доля похибки дорівнює 2 і не може бути встановленою більше ніж кількість рядків контексту у контекстному diff, звичайно - 3. |
**-g** _число_ або --get=_число_ | Ця опція керує діями **patch** , коли файл знаходиться під контролем RCS або SCCS але відсутній або має дозвіл тільки на читання, одночасно співпадаючи з версією за замовчуванням, або файл знаходиться під контролем ClearCase але відсутній. Якщо _число_ є додатковим, **patch ** добуде файл з системи контролю над модифікаціями (revision control system, RCS). Якщо _число _ дорівнює 0, **patch ** ігнорує RCS, ClearCase і SCCS і не добуває файлу. Якщо _число _ від'ємне, **patch** спитає користувача чи добувати файл. Значення для цієї опції можна встановити через змінну середовища **PATCH_GET** ; якщо її не встановлено, типовим значенням буде 0, коли **patch ** узгоджено з POSIX і від'ємне у протилежному випадку. |
**--help** | Виведе підсумок опцій і вийде. |
**-i** _файл_ або **--input=**_файл_ | Читати _файл _ як файл латки. Якщо аргумент _файл _ опушений, читатиме зі стандартного вводу. |
**-l** або **--ignore-whitespace** | Приблизне співпадання зі зразками, у випадку якщо табуляція або пробіли прийшли в безладдя у ваших файлах. Будь-яка послідовність одного або більше пропусків у файлі латки співпадають з будь-якою послідовністю оригіналу. Пропуски в кінці рядків буде ігноровано. Звичайні знаки, тим не менш, повинні збігатись точно. Кожний рядок контексту повинен все ще співпадати з рядком з оригінального файлу. |
**-n** або **--normal** | Розглядати латку як звичайний diff. |
**-N** або **--forward** | Ігнорувати латки що здаються оберненими (у оберненому напрямку) або вже вжитими. |
**-o** _файл_виводу_ або **--output=**_файл_виводу_ | Послати вивід до _файлу_виводу_ , замість латати той самий файл. |
**-p**_число_ або **--strip=**_число_ | Очистить найменший префікс що втримує _число _ передуючих слешів з кожної назви файлу, знайденої у файлі латки. Послідовність однієї або більше суміжних слешів розглядається як один слеш. Це керує тим як назви файлів, знайдених у латці, обробляються, у випадку, якщо ви зберігаєте ваші файли у відмінній директорії від тої, в якій їх зберігала особа, яка надіслала латку. Наприклад, скажімо назва файлу у латці була /u/howard/src/blurfl/blurfl.c тоді встановлення **-p0 ** залишить назву файлу незмінною, тоді як **-p1 ** видасть u/howard/src/blurfl/blurfl.c тобто видалить перший слеш, а **-p4 ** вкаже назву blurfl/blurfl.c Якщо не вказувати **-p ** взагалі, ви отримаєте _blurfl.c_ . Вказана таким чином назва файлу буде шукатись або в поточному каталозі, або в каталозі, вказаному опцією **-d** . |
**--posix** |
Слідує точніше стандарту POSIX, а саме: • Візьме перший існуючий файл зі списку (старий, новий, індекс) під час спроби вгадати назви файлів з заголовків diff. • Не видалятиме порожні файли після латання. • Не питатиме чи добувати файли з RCS, ClearCase або SCCS. • Не робитиме резервних копій файлів у випадку неспівпадання. |
**--quoting-style=** _слово_ |
Використати стиль _слово _ під час виводу назв (файлів). _Слово_ , що описує стиль може бути одним з наступних:
|
**litelal** | Виводить назви такими, які вони є. |
**shell** | Екранує назви для оболонки, якщо вони містять метазнаки, або можуть викликати неоднозначний вивід. |
**shell-always** | Екранує назви для оболонки, навіть якщо вони не вимагають того. |
**c** | Екранує назви, як для ланцюжка мови C. |
**escape** | Екранує, схоже до попереднього **c** , але без навколишніх подвійних лапок. |
Ви можете задати аргумент --quoting-style у змінній середовища QUOTING_STYLE . Якщо ця змінна не встановлена, значенням за узгодженням буде shell .
**-r** _rejectfile_ або **--reject-file=**_rejectfile_ | Помістить відкинуті латки у вказаний вами файл _rejectfile_, замість стандартного **.rej** . |
**-R** або **--reverse** | Припустити що латка була створена зі старим і новим файлом поміняними місцями. (Так, це час від часу стається, ми не досконалі.) **patch** спробує переставити місцями кожний кусок, перед тим як записати їх. (Тобто рядки, що починалися з **+** будуть починатися з **-**, і навпаки.) Відкинуті куски також будуть записані до **.rej ** у переставленому форматі. Опція **-R ** не працює з латками у формі скрипта для **ed** , оскільки вони надають замало інформації для створення обернутої латки. Якщо перший кусок латки зазнав невдачі, **patch ** обертає кусок, щоб побачити, чи можливо його вжити таким способом. Якщо, так, вас спитають, чи ви не хочете встановити опцію **-R** . У протилежному випадку, **patch ** продовжує як звичайно. (Примітка: ця метода ме може виявити обернуту латку у випадку звичайного diff і якщо першою командою стоїть конкатенація, оскільки долучення до файлу завжди матиме успіх (завдячуючи тому фактові, що нульовий контекст співпадає зі всім). На щастя, більшість латок додають або змінюють рядки, замість вилучати їх, тож більшість обернутих латок починаються з команди вилучення, яка зазнає невдачі і викликає дану евристику.) |
**-s** або **--silent** або **--quiet** | Діє безмовно, хіба станеться помилка. |
**-t** або **--batch** | Пригнічує запитання, схоже до **-f** , але з деякими відмінними умовами: не бере до уваги латки, чиї заголовки не містять назв файлів (схожа цим до **-f** ); пропускає латки, якщо версія файлу не співпала з рядком **Prereq: ** у латці; припускає, що латки обернуті, якщо вони такими виглядають. |
**-T** або **--set-time** | Встановить час модифікації і доступу до обробленого файлу рівним часовим міткам, знайденим у контекстних заголовків diff, припускаючи, що контекстні заголовки diff використовують локальний час. Ця опція не рекомендується, оскільки латки з використанням локального часу не завжди можуть бути використані тими, що мешкають у відмінних часових поясах, також тому, що локальний час може бути двозначним у випадку переходу на літній час. Замість вживання цієї опції, краще створюйте латки з UTC (Координованим Універсальним Часом) і використовувати опцію **-Z ** або **--set-utc ** з **patch ** натомість. |
**-u** або **--unified** | Вважати файл латки уніфікованим контекстним diff. |
**-v** або **--version** | Вивести заголовок з датою оновлення програми **patch ** і рівень латок і вийти. |
**-V** _метода_ або **--version-control=**_метода_ |
Використати вказану _методу _ для надання назв резервним копіям. Метода також може бути вказаною у змінній середовища **PATCH_VERSION_CONTROL ** (або, якщо останню не встановлено - **VERSION_CONTROL** ), яка буде переважена, тим не менш, цією командною опцією. Метода не впливає на те, чи здійснюється резервне копіювання, чи ні - тільки на те як резервні копії буде названо.
Значення, що може надаватися _методі _ схожі до відповідних значень змінної GNU Emacs 'version-control'; **patch ** також розпізнає наочніші синоніми. Чинними назвами _метод _ є (можуть бути також унікальні скорочення):
|
**existing** або **null** | Здійснює нумеровані копії файлів, що вже мають резервні копії, у протилежному випадку - звичайні копії. Ця метода використовувана за замовчуванням. |
**numbered** або **t** | Створить нумеровані резервні копії. Назва резервної копії файлу _F_ виглядатиме як _F_.~_N_~, де _N_ - це номер версії. |
**simple** або **never** | Здійснює прості резервні копії. Прапорці **-B ** або **--prefix** , **-Y** або **--basename-prefix ** і **-z ** або **--suffix ** вказують як назвати звичайну резервну копію. Якщо жоден з цих прапорців не вказано, тоді використовується суфікс простого резервування, знайдений у змінній середовища **SIMPLE_BACKUP_SUFFIX** , або **.orig** , якщо її не встановлено. |
У випадку numbered або sipmple , резервних копій, якщо назва копії виявиться занадто довгою, буде використано просто суфікс ~ . Якщо навіть ~ утворює занадто довгу назву, тоді ~ візьме місця останньої літери назви файлу.
**--verbose** | Виводить додаткову інформацію про здійснюване. |
**-x** _число_ або **--debug=**_число_ | Встановлює внутрішні прапорці зневадження програми **patch** . Цікаве лише розробникам **patch** . |
**-Y** _префікс_ or **--basename-prefix=**_префікс_ | Добавить вказаний префікс до основного імені файлу під час створення простої резервної копії. Прикладом, опція **-Y .del/ ** для простої резервної копії файлу _src/patch/util.c_ , створить _src/patch/.del/util.c_ . |
**-z** _суфікс_ або **--suffix=**_суфікс_ | Використає _суфікс _ як суфікс простої резервної копії. Наприклад, **-z ** - для простої резервної копії файлу _src/patch/util.c_ , створить _src/patch/util.c-_ . Суфікс резервного копіювання можна також вказати у змінній середовища **SIMPLE_BACKUP_SUFFIX** , яка буде переважена, тим не менш, цією командною опцією. |
**-Z** або **--set-utc** | Встановить час модифікації і доступу обробленого файлу до значень міток часу, знайдених у контекстних заголовках diff, за умови, що ці заголовки використовують формат Координованого Універсального Часу (UTC, згадуваного також як GMT). Дивіться також опцію **-T ** або **--set-time** . Опції **-Z ** або **--set-utc ** так само як **-T ** або **--set-time** , як правило, втримуються від зміни часових характеристик, якщо оригінальний час файлу не співпадає зі вказаним у заголовку латки або, якщо зміст файлу не цілком співпадає з тим, що в латці. Проте, якщо надати **-f ** або **--force ** опції, час буде змінено беззастережно. |
СЕРЕДОВИЩ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 у Юніксах.
**VERSION_CONTROL** або **PATCH_VERSION_CONTROL** | Вибирає стиль контролю версій файлів. Дивіться опції **-v** або **--version-control**. |
ФАЙЛИ
_$TMPDIR_**/p*** | тимчасові файли |
**/dev/tty** | контрольний термінал; використовується, щоб отримати відповіді на запитання, задані користувачеві |
ДИВІТЬСЯ ТАКОЖ
Запропонований 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
Поясніть отримувачам як застосувати латку, вказуючи в яку директорію перейти і які опції patch вжити. Рекомендованою є опція -Np1. Перевірте латки на власній системі, вдаючи ніби ви є отримувачем.
Ви можете запобігти багатьом нещастям, якщо зберігатимете файл 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
оскільки ці дві назви файлів включають різну кількість слешів і різні версії patch можуть інтерпретувати ці назви файлів по-різному. Щоб запобігти плутанини, вишліть латку, що виглядатиме як наступне:
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
Уникайте створення латок, що порівнюють резервні файли, наприклад README.orig, так як це може заплутати patch і залатати резервний файл замість дійсного. Натомість використовуйте латки, що порівнюють ту саму основну назву але у різних каталогах, наприклад old/README і new/README.
Будьте обережними не посилати обернуті латки, оскільки це заставляє людей серйозно задуматись, чи вони застосували вже латку, чи ні.
Намагайтесь, щоб ваші латки не змінювали похідні файли (наприклад, файл 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