patch - применить файл с изменениями к оригиналу
СИНТАКСИС
patch [опции] [оригинальный_файл [файл_с_изменениями]]
но обычно:
patch -pномер <файл_с_изменениями>
ОПИСАНИЕ
patch принимает файл с изменениями `файл_с_изменениями`, содержащий список различий, созданный программой diff, и применяет эти изменения к одному или нескольким исходным файлам, создавая измененные версии. Обычно измененные версии помещаются на место исходных файлов. Можно создавать резервные копии; см. опцию -b или --backup. Имена файлов, которые необходимо изменить, обычно берутся из файла с изменениями, но если необходимо изменить только один файл, его можно указать в командной строке как `оригинальный_файл`.
При запуске patch пытается определить тип списка различий, если только это не переопределено опциями -c (--context), -e (--ed), -n (--normal) или -u (--unified). Изменения в контексте (старый стиль, новый стиль и объединенный) и обычные изменения применяются самой программой patch, в то время как изменения в стиле ed просто передаются в редактор ed(1) через канал.
patch пытается пропустить любой начальный мусор, применить изменения, а затем пропустить любой конечный мусор. Таким образом, можно передать сообщение электронной почты, содержащее список изменений, в patch, и это должно работать. Если все изменения имеют одинаковый отступ, если строки заканчиваются символами CRLF или если изменения один или несколько раз заключены в оболочку путем добавления "- " в начало строк, начинающихся с "-", как указано в Internet RFC 934, это учитывается. После удаления отступов или оболочки строки, начинающиеся с "#", игнорируются, поскольку они считаются комментариями.
Для изменений в контексте и, в меньшей степени, для обычных изменений, patch может обнаруживать, когда номера строк, указанные в изменениях, неверны, и пытается найти правильное место для применения каждого блока изменений. В качестве первого предположения patch берет номер строки, указанный для блока, плюс или минус смещение, используемое при применении предыдущего блока. Если это неверное место, patch сканирует как вперед, так и назад в поисках набора строк, соответствующих контексту, указанному в блоке. Сначала patch ищет место, где все строки контекста совпадают. Если такое место не найдено, и это изменения в контексте, и максимальный коэффициент размытия установлен в 1 или больше, то выполняется еще одно сканирование, при котором игнорируется первая и последняя строки контекста. Если это не удается, и максимальный коэффициент размытия установлен в 2 или больше, то игнорируются первые две и последние две строки контекста, и выполняется еще одно сканирование. (Значение по умолчанию для максимального коэффициента размытия равно 2.)
Блоки с меньшим количеством префиксного контекста, чем суффиксный контекст (после применения размытия), должны применяться в начале файла, если их первая строка имеет номер 1. Блоки с большим количеством префиксного контекста, чем суффиксный контекст (после применения размытия), должны применяться в конце файла.
Если в патче не удается найти место для установки фрагмента, этот фрагмент помещается в файл отклоненных изменений (reject file), который обычно имеет имя выходного файла с добавленным суффиксом .rej, или #, если .rej приведет к слишком длинному имени файла (если даже добавление одного символа # делает имя файла слишком длинным, то # заменяет последний символ имени файла).
Отклоненный фрагмент выводится в формате унифицированного или контекстного диффа. Если входные данные были обычным диффом, то многие контексты будут просто пустыми. Номера фрагментов в файле отклоненных изменений могут отличаться от номеров в файле патча: они отражают приблизительное место, где патч, по его мнению, должен был поместить неудавшиеся фрагменты в новом файле, а не в старом.
После завершения каждого фрагмента пользователю сообщается, был ли фрагмент успешно установлен, и если нет, то на какой строке (в новом файле) патч, по его мнению, должен был его поместить. Если фрагмент установлен на другой строке, чем указано в диффе, пользователю сообщается смещение. Большое смещение может указывать на то, что фрагмент был установлен не в том месте. Также пользователю сообщается, использовался ли коэффициент нечеткого сопоставления (fuzz factor), в этом случае следует быть немного осторожным. Если указана опция --verbose, пользователю также сообщается об успешно сопоставленных фрагментах.
Если в командной строке не указан исходный файл origfile, патч пытается определить имя файла, который нужно редактировать, на основе начального "мусора", используя следующие правила.
Во-первых, патч создает упорядоченный список кандидатов в имена файлов следующим образом:
Если заголовок соответствует контекстному диффу, патч берет старое и новое имена файлов из заголовка. Имя игнорируется, если в нем недостаточно слешей для удовлетворения опции -pnum или --strip=num. Имя /dev/null также игнорируется.
Если в начальном "мусоре" есть строка Index: и либо старое, либо новое имя отсутствует, либо патч соответствует стандарту POSIX, патч берет имя из строки Index:.
Для целей следующих правил имена файлов-кандидатов рассматриваются в порядке (старый, новый, индекс), независимо от порядка, в котором они появляются в заголовке.
Затем патч выбирает имя файла из списка кандидатов следующим образом:
Если некоторые из указанных файлов существуют, патч выбирает первое имя, если соответствует стандарту POSIX, и лучшее имя в противном случае.
Если патч не игнорирует RCS, ClearCase, Perforce и SCCS (см. опцию -g num или --get=num), и ни один из указанных файлов не существует, но найден главный файл RCS, ClearCase, Perforce или SCCS, патч выбирает первый указанный файл с главным файлом RCS, ClearCase, Perforce или SCCS.
Если ни один из указанных файлов не существует, не найден главный файл RCS, ClearCase, Perforce или SCCS, даны некоторые имена, патч не соответствует стандарту POSIX и патч, по-видимому, создает файл, патч выбирает лучшее имя, требующее создания наименьшего количества каталогов.
Если из вышеописанных эвристик не получится получить имя файла, программа запросит имя файла, который нужно пропатчить, и команда patch выберет это имя.
Чтобы определить лучший вариант из непустого списка имен файлов, команда patch сначала выбирает все имена с наименьшим количеством компонентов пути; из них затем выбираются все имена с самым коротким именем файла; из них затем выбираются все самые короткие имена; и, наконец, выбирается первое оставшееся имя.
Кроме того, если в начальной части файла содержится строка Prereq:, команда patch берет первое слово из этой строки (обычно номер версии) и проверяет, можно ли найти это слово в исходном файле. Если нет, то команда patch запрашивает подтверждение, прежде чем продолжить.
В итоге, вы должны иметь возможность выполнить что-то вроде следующей команды оболочки:
patch -d /usr/src/local/blurfl
и пропатчить файл в каталоге blurfl непосредственно из патча, который читается из стандартного ввода.
Если файл патча содержит более одного патча, команда patch пытается применить каждый из них, как если бы они были получены из отдельных файлов патчей. Это означает, в частности, что предполагается, что имя файла, который нужно пропатчить, должно быть определено для каждого списка изменений, и что в начальной части каждого списка изменений содержится полезная информация, такая как имена файлов и уровень ревизии, как указано выше.
ОПЦИИ
-b или --backup
Создавать резервные копии файлов. То есть, при пропатчивании файла, переименовывать или копировать исходный файл вместо его удаления. См. опцию -V или --version-control для получения подробной информации о том, как определяются имена файлов резервных копий.
--backup-if-mismatch
Создать резервную копию файла, если патч не соответствует файлу, и если резервные копии не запрошены иным образом. Это значение по умолчанию, если команда patch не соответствует стандарту POSIX.
--no-backup-if-mismatch
Не создавать резервную копию файла, если патч не соответствует файлу, и если резервные копии не запрошены иным образом. Это значение по умолчанию, если команда patch соответствует стандарту POSIX.
-B pref или --prefix=pref
Использовать простой метод для определения имен файлов резервных копий (см. опцию -V или --version-control) и добавлять префикс pref к имени файла при создании имени файла резервной копии. Например, при использовании -B /junk/ простое имя файла резервной копии для src/patch/util.c будет /junk/src/patch/util.c.
--binary
Записывать все файлы в двоичном режиме, за исключением стандартного вывода и /dev/tty. При чтении отключать эвристику для преобразования окончаний строк CRLF в LF. Эта опция необходима в системах POSIX при применении патчей, сгенерированных в не-POSIX системах, к не-POSIX файлам. (В системах POSIX операции чтения и записи файлов никогда не преобразуют окончания строк. В Windows операции чтения и записи по умолчанию преобразуют окончания строк, и патчи должны генерироваться с помощью diff --binary, когда окончания строк имеют значение.)
-c или --context
Интерпретировать файл патча как обычный патч в формате контекста.
-d dir или --directory=dir
Перейти в каталог dir непосредственно перед выполнением каких-либо других действий.
-D define или --ifdef=define
Используйте конструкцию #ifdef ... #endif для обозначения изменений, используя define в качестве различающего символа.
--dry-run
Вывести результаты применения патчей, не изменяя фактически никаких файлов.
-e или --ed
Интерпретировать файл патча как сценарий ed.
-E или --remove-empty-files
Удалять выходные файлы, которые оказываются пустыми после применения патчей. Обычно этот параметр не нужен, так как patch может проверить временные метки в заголовке, чтобы определить, должен ли файл существовать после исправления. Однако, если входные данные не являются контекстным diff или если patch соответствует POSIX, patch не удаляет пустые исправленные файлы, если не указан этот параметр. При удалении файла patch также пытается удалить все пустые родительские каталоги.
-f или --force
Предполагать, что пользователь точно знает, что делает, и не задавать никаких вопросов. Пропускать патчи, в заголовках которых не указано, какой файл нужно исправить; исправлять файлы, даже если у них неправильная версия для строки Prereq: в патче; и считать, что патчи не перевернуты, даже если они выглядят таковыми. Этот параметр не подавляет комментарии; используйте -s для этого.
-F число или --fuzz=число
Установить максимальный коэффициент нечеткости. Этот параметр применяется только к diff'ам, имеющим контекст, и заставляет patch игнорировать до указанного количества строк контекста при поиске мест для установки куска. Обратите внимание, что больший коэффициент нечеткости увеличивает вероятность ошибочного патча. Коэффициент нечеткости по умолчанию равен 2. Коэффициент нечеткости, больший или равный количеству строк контекста в контекстном diff, обычно 3, игнорирует весь контекст.
-g число или --get=число
Этот параметр управляет действиями patch, когда файл находится под контролем RCS или SCCS и не существует, либо доступен только для чтения и соответствует версии по умолчанию, или когда файл находится под контролем ClearCase или Perforce и не существует. Если число положительное, patch получает (или извлекает) файл из системы контроля версий; если ноль, patch игнорирует RCS, ClearCase, Perforce и SCCS и не получает файл; а если отрицательное, patch спрашивает пользователя, нужно ли получить файл. Значение этого параметра по умолчанию задается значением переменной окружения PATCH_GET, если она установлена; если нет, значение по умолчанию равно нулю.
--help
Вывести краткую справку по параметрам и выйти.
-i файл_патча или --input=файл_патча
Читать патч из файла_патча. Если файл_патча равен -, читать со стандартного ввода (по умолчанию).
-l или --ignore-whitespace
Нестрого сопоставлять шаблоны, на случай если табуляции или пробелы были искажены в ваших файлах. Любая последовательность из одного или более пробелов в файле патча соответствует любой последовательности в исходном файле, а последовательности пробелов в концах строк игнорируются. Обычные символы по-прежнему должны совпадать точно. Каждая строка контекста по-прежнему должна соответствовать строке в исходном файле.
--merge или --merge=merge или --merge=diff3
Выполнить слияние файла патча с исходными файлами подобно diff3(1) или merge(1). При обнаружении конфликта patch выводит предупреждение и заключает конфликт в строки <<<<<<< и >>>>>>>. Типичный конфликт будет выглядеть так:
<<<<<<<
строки из исходного файла
|||||||
исходные строки из патча
=======
новые строки из патча
>>>>>>>
Необязательный аргумент --merge определяет формат вывода для конфликтов: формат diff3 отображает раздел ||||||| с исходными строками из патча; в формате merge этот раздел отсутствует. Формат merge является форматом по умолчанию.
Эта опция подразумевает --forward и не учитывает опцию --fuzz=num.
-n или --normal
Интерпретируйте файл патча как обычный diff.
-N или --forward
Когда патч не применяется, patch обычно проверяет, не был ли патч уже применен, пытаясь выполнить обратное применение первого блока. Опция --forward предотвращает это. См. также -R.
-o outfile или --output=outfile
Отправьте вывод в файл outfile вместо непосредственного изменения файлов. Не используйте эту опцию, если outfile является одним из файлов, подлежащих изменению. Если outfile — это -, отправьте вывод в стандартный вывод и отправьте все сообщения, которые обычно отправляются в стандартный вывод, в стандартный поток ошибок.
-pnum или --strip=num
Удалите наименьший префикс, содержащий num начальных слешей, из каждого имени файла, найденного в файле патча. Последовательность из одного или нескольких смежных слешей считается одним слешем. Это определяет, как обрабатываются имена файлов, найденные в файле патча, в случае, если вы храните файлы в другом каталоге, чем тот, кто отправил патч. Например, предположим, что имя файла в файле патча:
/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, Perforce или SCCS.
Требуйте, чтобы все опции предшествовали файлам в командной строке.
Не создавайте резервные копии файлов в случае несоответствия.
--quoting-style=word
Используйте стиль word для цитирования имен вывода. Слово должно быть одним из следующих:
literal
Выводите имена как есть.
shell
Цитируйте имена для оболочки, если они содержат специальные символы оболочки или вызывают неоднозначный вывод.
shell-always
Цитируйте имена для оболочки, даже если обычно цитирование не требуется.
c
Цитируйте имена, как для строки на языке C.
escape
Цитируйте, как в случае с c, за исключением того, что опускайте окружающие двойные кавычки.
Вы можете указать значение по умолчанию для опции --quoting-style с помощью переменной среды QUOTING_STYLE. Если эта переменная среды не установлена, значением по умолчанию является shell.
-r rejectfile или --reject-file=rejectfile
Помещает отклоненные фрагменты в файл rejectfile вместо файла .rej по умолчанию. Если rejectfile равен -, отклоненные фрагменты отбрасываются.
-R или --reverse
Предполагает, что этот патч был создан с перепутанными старым и новым файлами. (Да, такое иногда случается, такова уж человеческая природа.) patch пытается изменить каждый фрагмент, прежде чем применить его. Отклоненные фрагменты выводятся в перевернутом формате. Опция -R не работает с diff-скриптами ed, потому что в них недостаточно информации для восстановления обратной операции.
Если первый фрагмент патча не удается применить, patch переворачивает этот фрагмент, чтобы посмотреть, можно ли его применить таким образом. Если это возможно, пользователю предлагается установить опцию -R. Если это невозможно, патч применяется обычным образом. (Примечание: этот метод не может обнаружить перевернутый патч, если это обычный diff, и если первая команда является командой добавления (т. е. она должна быть командой удаления), поскольку команды добавления всегда выполняются, поскольку нулевой контекст соответствует любому месту. К счастью, большинство патчей добавляют или изменяют строки, а не удаляют их, поэтому большинство перевернутых обычных diff начинаются с команды удаления, которая не выполняется, что запускает эвристику.)
--read-only=behavior
Действуйте в соответствии с запросом при попытке изменить файл, доступный только для чтения: игнорируйте потенциальную проблему, предупреждайте об этом (по умолчанию) или завершайте работу.
--reject-format=format
Создавайте файлы отклонений в указанном формате (контекст или унифицированный). Без этой опции отклоненные фрагменты выводятся в формате унифицированного diff, если входной патч был в этом формате, в противном случае в обычном формате контекстного diff.
-s или --silent или --quiet
Работайте в тихом режиме, если не произойдет ошибка.
--follow-symlinks
При поиске входных файлов следуйте по символическим ссылкам. Заменяйте символические ссылки вместо изменения файлов, на которые указывают символические ссылки. Патчи в стиле Git для символических ссылок больше не будут применяться. Эта опция существует для обратной совместимости с предыдущими версиями patch; ее использование не рекомендуется.
-t или --batch
Подавляйте вопросы, как и -f, но делайте некоторые другие предположения: пропускайте патчи, заголовки которых не содержат имен файлов (аналогично -f); пропускайте патчи, для которых файл имеет неверную версию для строки Prereq: в патче; и предполагайте, что патчи перевернуты, если это выглядит так.
-T или --set-time
Установите время изменения и доступа к измененным файлам на основе временных меток, указанных в заголовках контекстного diff. Если в заголовках контекстного diff это не указано, предполагайте, что они используют местное время.
Использование этой опции с временными метками, которые не содержат часовые пояса, не рекомендуется, потому что патчи, использующие местное время, не могут легко использоваться людьми в других часовых поясах, и потому что локальные временные метки неоднозначны, когда местные часы переходят на зимнее время. Убедитесь, что временные метки содержат часовые пояса, или создавайте патчи с использованием UTC и используйте опцию -Z или --set-utc.
-u или --unified
Интерпретируйте файл патча как унифицированный контекстный диф.
-v или --version
Выведите заголовок ревизии и уровень патча и завершите работу.
-V метод или --version-control=метод
Используйте метод для определения имен файлов резервных копий. Метод также можно указать с помощью переменной среды PATCH_VERSION_CONTROL (или, если она не задана, переменной VERSION_CONTROL), которая переопределяется этой опцией. Метод не влияет на то, создаются ли файлы резервных копий; он влияет только на имена любых создаваемых файлов резервных копий.
Значение параметра метод аналогично переменной version-control GNU Emacs; patch также распознает синонимы, которые являются более описательными. Допустимые значения для параметра метод:
existing или nil
Создавайте нумерованные резервные копии файлов, у которых они уже есть, в противном случае создавайте простые резервные копии. Это значение по умолчанию.
numbered или t
Создавайте нумерованные резервные копии. Имя файла нумерованной резервной копии для F — F.~N~, где N — номер версии.
simple или never
Создавайте простые резервные копии. Опции -B или --prefix, -Y или --basename-prefix и -z или --suffix указывают имя файла простой резервной копии. Если ни одна из этих опций не указана, используется простое имя файла резервной копии; это значение переменной среды SIMPLE_BACKUP_SUFFIX, если она задана, и в противном случае — .orig.
При использовании нумерованных или простых резервных копий, если имя файла резервной копии слишком длинное, используется суффикс резервной копии ~. Если даже добавление ~ сделает имя слишком длинным, то ~ заменяет последний символ имени файла.
--verbose
Выводите дополнительную информацию о выполняемой работе.
-x num или --debug=num
Установите внутренние отладочные флаги, представляющие интерес только для разработчиков patch.
-Y префикс или --basename-prefix=префикс
Используйте простой метод для определения имен файлов резервных копий (см. опцию -V метод или --version-control метод) и добавьте префикс префикс к базовому имени имени файла при создании имени его файла резервной копии. Например, при использовании -Y .del/ имя файла простой резервной копии для src/patch/util.c будет src/patch/.del/util.c.
-z суффикс или --suffix=суффикс
Используйте простой метод для определения имен файлов резервных копий (см. опцию -V метод или --version-control метод) и используйте суффикс в качестве суффикса. Например, при использовании -z - имя файла резервной копии для src/patch/util.c будет src/patch/util.c-.
-Z или --set-utc
Установите время изменения и доступа к исправленным файлам на основе временных меток, указанных в заголовках контекстного диффа. Если не указано в временных метках, предполагается, что в заголовках контекстного диффа используется координированное универсальное время (UTC), также известное как GMT. См. также опцию -T или --set-time.
Обычно опции -Z или --set-utc и -T или --set-time не устанавливают время файла, если исходное время файла не соответствует времени, указанному в заголовке патча, или если его содержимое не соответствует патчу точно. Однако, если указана опция -f или --force, время файла устанавливается независимо от этого.
Из-за ограничений формата вывода diff, эти опции не могут обновлять время файлов, содержимое которых не изменилось. Кроме того, если вы используете эти опции, вам следует удалить (например, с помощью make clean) все файлы, которые зависят от измененных файлов, чтобы последующие вызовы make не приводили к путанице из-за времени измененных файлов.
ОКРУЖАЮЩАЯ СРЕДА
PATCH_GET
Определяет, получает ли patch отсутствующие или доступные только для чтения файлы из RCS, ClearCase, Perforce или SCCS по умолчанию; см. опции -g или --get.
POSIXLY_CORRECT
Если установлено, patch более строго соответствует стандарту POSIX по умолчанию: см. опцию --posix.
QUOTING_STYLE
Значение по умолчанию для опции --quoting-style.
SIMPLE_BACKUP_SUFFIX
Расширение, которое следует использовать для имен простых резервных файлов вместо .orig.
TMPDIR, TMP, TEMP
Каталог для размещения временных файлов; patch использует первую переменную среды в этом списке, которая установлена. Если ни одна из них не установлена, значение по умолчанию зависит от системы; обычно это /tmp в системах Unix.
VERSION_CONTROL или PATCH_VERSION_CONTROL
Выбирает стиль контроля версий; см. опции -v или --version-control.
ФАЙЛЫ
$TMPDIR/p*
временные файлы
/dev/tty
управляющий терминал; используется для получения ответов на вопросы, задаваемые пользователю
СМОТРИТЕ ТАКЖЕ
diff(1), ed(1), merge(1).
Маршалл Т. Роуз и Эйнар А. Стефферуд, Предлагаемый стандарт для инкапсуляции сообщений, Интернет RFC 934 [https://datatracker.ietf.org/doc/html/rfc934] (1985-01).
ЗАМЕЧАНИЯ ДЛЯ ОТПРАВИТЕЛЕЙ ПАТЧЕЙ
Есть несколько вещей, о которых вам следует помнить, если вы собираетесь отправлять патчи.
Создавайте свой патч систематически. При использовании системы контроля версий это должно быть легко; например, с помощью Git вы можете использовать git diff. В противном случае хорошим методом является команда diff -Naur old new, где old и new определяют старый и новый каталоги. Имена old и new не должны содержать никаких слешей.
Если патч должен передавать временные метки файлов, а также содержимое файлов, заголовки команд diff должны содержать даты и время в универсальном времени с использованием традиционного формата Unix, чтобы получатели патча могли использовать опцию -Z или --set-utc. Вот пример команды для создания таких заголовков с использованием синтаксиса Bourne shell:
LC_ALL=C TZ=UTC0 diff -Naur myprog-2.7 myprog-2.8
Сообщите своим получателям, как применить патч, указав, в какой каталог им нужно перейти (cd) и какие опции patch использовать. Рекомендуется использовать строку опций -Np1. Проверьте свою процедуру, притворившись получателем и применив свой патч к копии исходных файлов.
Вы можете избавить людей от множества проблем, создав файл patchlevel.h, который будет обновляться при каждом применении патча в качестве первого элемента в файле патча, который вы отправляете. Если вы поместите строку Prereq: в патч, он не позволит им применять патчи не по порядку без предупреждения.
Вы можете создать файл, отправив diff, который сравнивает /dev/null или пустой файл, датированный эпохой (1970-01-01 00:00:00 UTC), с файлом, который вы хотите создать. Это работает только в том случае, если файл, который вы хотите создать, еще не существует в целевом каталоге. И наоборот, вы можете удалить файл, отправив контекстный diff, который сравнивает файл, который нужно удалить, с пустым файлом, датированным эпохой. Файл будет удален, если только 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 2024
+++ prog/README Mon Mar 17 14:58:22 2024
потому что имена двух файлов имеют разное количество слешей, и разные версии patch интерпретируют имена файлов по-разному. Чтобы избежать путаницы, отправляйте вывод, который выглядит так:
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
Избегайте отправки патчей, сравнивающих имена файлов резервных копий, таких как README.orig, поскольку это может привести к тому, что patch будет применять патч к файлу резервной копии, а не к фактическому файлу. Вместо этого отправляйте патчи, сравнивающие одни и те же имена базовых файлов в разных каталогах, например, old/README и new/README.
Будьте осторожны, чтобы не отправлять перевернутые патчи, так как это может заставить людей задуматься, не применяли ли они уже этот патч.
Постарайтесь не создавать патчи, которые изменяют производные файлы (например, файл configure, в котором есть строка configure: configure.ac в вашем файле Makefile), поскольку получатель должен иметь возможность повторно сгенерировать производные файлы. Если вам необходимо отправлять diff-файлы производных файлов, создавайте diff-файлы, используя UTC, заставляйте получателей применять патч с помощью опции -Z или --set-utc и удаляйте любые неподправленные файлы, которые зависят от исправленных файлов (например, с помощью команды make clean).
Хотя вы можете добиться того, чтобы в один файл поместилось 582 записи diff, возможно, будет разумнее сгруппировать связанные патчи в отдельные файлы на случай, если что-то пойдет не так.
ДИАГНОСТИКА
Диагностика обычно указывает на то, что patch не смог разобрать ваш файл патча.
Если указана опция --verbose, сообщение Hmm... указывает на то, что в файле патча есть необработанный текст, и patch пытается интуитивно понять, есть ли в этом тексте патч и, если да, то какого типа.
Статус выхода patch равен 0, если все фрагменты успешно применены, 1, если некоторые фрагменты не могут быть применены или возникли конфликты при объединении, и 2, если возникли более серьезные проблемы. При применении набора патчей в цикле вам следует проверять этот статус выхода, чтобы не применить более поздний патч к частично исправленному файлу.
ОГРАНИЧЕНИЯ
Контекстные diff-файлы не могут надежно представлять создание или удаление пустых файлов, пустых каталогов или специальных файлов, таких как символические ссылки. Они также не могут представлять изменения метаданных файлов, таких как владение, разрешения или является ли один файл жесткой ссылкой на другой. Если требуются и другие изменения, вместе с патчем должны быть предоставлены отдельные инструкции (например, сценарий оболочки), чтобы выполнить их.
Инструмент `patch` не может определить, смещены ли номера строк в скрипте ed, и может обнаружить некорректные номера строк в обычном diff только в том случае, если он находит изменение или удаление. Контекстный diff с коэффициентом размытия 3 может иметь ту же проблему. В таких случаях, вероятно, следует использовать контекстный diff, чтобы убедиться, что внесенные изменения имеют смысл. Конечно, успешная компиляция без ошибок — довольно хороший показатель того, что патч сработал, но это не всегда так.
Обычно `patch` выдает правильные результаты, даже когда ему приходится много угадывать. Однако результаты гарантированно будут правильными только в том случае, если патч применяется к точно такой же версии файла, для которой он был создан.
ПРОБЛЕМЫ СОВМЕСТИМОСТИ
Стандарт POSIX определяет поведение, которое отличается от GNU patch.
В POSIX patch, если не используется опция -b, резервные копии не создаются, даже если есть несовпадение. В GNU patch это поведение включено с помощью опции --no-backup-if-mismatch или путем соответствия POSIX с помощью опции --posix или путем установки переменной среды POSIXLY_CORRECT.
При определении имени файла, к которому применяется патч, на основе заголовка патча, patch использует сложный метод, который может быть настроен на соответствие POSIX. Метод эквивалентен POSIX, если имена файлов в заголовке контекстного diff и строке Index: идентичны после удаления префиксов. Ваш патч обычно совместим, если в заголовке каждого файла одинаковое количество слешей.
Ограничьте себя следующими опциями при отправке инструкций, предназначенных для выполнения кем-либо, использующим GNU patch или патч, соответствующий POSIX. Пробелы в следующем списке являются необязательными.
-b
-c
-d dir
-D define
-e
-i patchfile
-l
-n
-N
-o outfile
-p num
-R
-r rejectfile
-u
ОШИБКИ
Пожалуйста, сообщайте об ошибках по электронной почте на <_>.
Если код был дублирован (например, с помощью #ifdef OLDCODE ... #else ... #endif), patch не может изменить обе версии и, если он вообще работает, скорее всего, изменит не ту версию и сообщит вам, что он успешно выполнил задачу.
Если вы применяете патч, который уже применили, patch считает, что это обратный патч, и предлагает отменить применение патча. Это можно рассматривать как полезную функцию.
Вычисление способа объединения фрагмента значительно сложнее, чем использование стандартного алгоритма нечеткого сопоставления. Большие фрагменты, больше контекста, большее смещение от исходного местоположения и худшее соответствие замедляют алгоритм.
ЛИЦЕНЗИЯ
Copyright © 1989–2025 Free Software Foundation, Inc. Copyright © 1984–1986, 1988 Larry Wall.
Разрешается создавать и распространять точные копии этого руководства при условии сохранения уведомления об авторских правах и этого уведомления о разрешении на всех копиях.
Разрешается копировать и распространять модифицированные версии этого руководства на условиях, применимых к дословной копии, при условии, что вся полученная производная работа распространяется в соответствии с условиями идентичного уведомления об авторских правах.
Разрешается копировать и распространять переводы этого руководства на другой язык на вышеуказанных условиях для модифицированных версий, за исключением того, что это уведомление об авторских правах может быть включено в переводы, одобренные владельцами авторских прав, вместо оригинального английского текста.
АВТОРЫ
Ларри Уолл написал оригинальную версию patch. Пол Эггерт снял произвольные ограничения patch; добавил поддержку двоичных файлов, установку времени файлов и удаление файлов; и сделал его более соответствующим стандарту POSIX. Среди других участников — Уэйн Дэвисон, который добавил поддержку unidiff, и Дэвид Маккензи, который добавил поддержку конфигурации и резервного копирования. Андреас Грюнбахер добавил поддержку слияния.