patch - aplicar um arquivo diff a um original
SINTAXE
patch [opções] [arquivooriginal [arquivodiff]]
mas geralmente apenas
patch -pnum <arquivodiff
DESCRIÇÃO
patch recebe um arquivo de patch, arquivodiff, contendo uma listagem de diferenças produzida pelo programa diff
e aplica essas diferenças a um ou mais arquivos originais, produzindo versões corrigidas. Normalmente, as versões corrigidas são colocadas no lugar dos arquivos originais. Cópias de segurança podem ser feitas; veja a opção -b ou
--backup. Os nomes dos arquivos a serem corrigidos geralmente são obtidos do arquivo de patch, mas
se houver apenas um arquivo a ser corrigido, ele pode ser especificado na linha de comando como arquivooriginal.
Ao iniciar, patch tenta determinar o tipo da listagem de diff, a menos que seja substituído por uma opção -c (--context), -e (--ed), -n (--normal) ou -u (--unified). Diffs de contexto (estilo antigo, novo estilo e unificado) e diffs normais são aplicados pelo programa patch, enquanto os diffs ed são simplesmente enviados ao editor ed(1) por meio de um pipe.
patch tenta ignorar qualquer lixo inicial, aplicar o diff e, em seguida, ignorar qualquer lixo final.
Assim, você pode enviar uma mensagem de e-mail contendo uma listagem de diff para patch e ele deve funcionar. Se
todo o diff for indentado por uma quantidade consistente, se as linhas terminarem em CRLF ou se um diff for
encapsulado uma ou mais vezes, adicionando "- " no início das linhas que começam com "-", conforme especificado no Internet
RFC 934, isso é levado em consideração. Após remover a indentação ou encapsulamento, as linhas que começam
com # são ignoradas, pois são consideradas comentários.
Com diffs de contexto e, em menor grau, com diffs normais, patch pode detectar quando os números de linha mencionados no patch estão incorretos e tenta encontrar o local correto para aplicar cada pedaço do patch. Como primeira estimativa, ele usa o número de linha mencionado para o pedaço, mais ou menos qualquer deslocamento usado na aplicação do pedaço anterior. Se esse não for o local correto, patch analisa tanto para frente quanto para trás em busca de um conjunto de linhas que correspondam ao contexto fornecido no pedaço. Primeiro, patch procura um local onde todas as linhas do contexto correspondam. Se nenhum local como esse for encontrado, e for um diff de contexto, e o fator de tolerância máximo for definido como 1 ou mais, então outra análise é feita, ignorando a primeira e a última linha do contexto. Se isso falhar e o fator de tolerância máximo for definido como 2 ou mais, as duas primeiras e as duas últimas linhas do contexto são ignoradas e outra análise é feita. (O fator de tolerância máximo padrão é 2.)
Pedaços com menos contexto de prefixo do que contexto de sufixo (após aplicar a tolerância) devem ser aplicados no início do arquivo se sua primeira linha for 1. Pedaços com mais contexto de prefixo do que contexto de sufixo (após aplicar a tolerância) devem ser aplicados no final do arquivo.
Se um patch não conseguir encontrar um local para instalar um determinado trecho do patch, ele colocará o trecho em um arquivo de rejeição, que normalmente tem o nome do arquivo de saída mais o sufixo ".rej", ou "#" se ".rej" gerar um nome de arquivo muito longo (se até mesmo anexar o caractere "#" tornar o nome do arquivo muito longo, então "#" substituirá o último caractere do nome do arquivo).
O trecho rejeitado é gerado no formato de diff unificado ou de contexto. Se a entrada era um diff normal, muitos dos contextos são simplesmente nulos. Os números das linhas nos trechos do arquivo de rejeição podem ser diferentes dos do arquivo de patch: eles refletem a localização aproximada em que o patch acredita que os trechos rejeitados devem estar no novo arquivo, em vez do arquivo antigo.
À medida que cada trecho é concluído, você é informado se o trecho falhou e, em caso afirmativo, em qual linha (no novo arquivo) o patch acreditava que o trecho deveria ser colocado. Se o trecho for instalado em uma linha diferente do número da linha especificado no diff, você será informado do deslocamento. Um único deslocamento grande pode indicar que um trecho foi instalado no local errado. Você também é informado se um fator de "fuzz" foi usado para fazer a correspondência, caso em que você também deve estar ligeiramente desconfiado. Se a opção --verbose for fornecida, você também será informado sobre os trechos que correspondem exatamente.
Se nenhum arquivo original (origfile) for especificado na linha de comando, o patch tentará determinar a partir do "lixo" inicial qual é o nome do arquivo a ser editado, usando as seguintes regras.
Primeiro, o patch pega uma lista ordenada de nomes de arquivo candidatos da seguinte forma:
Se o cabeçalho for o de um diff de contexto, o patch pega os nomes dos arquivos antigo e novo no cabeçalho. Um nome é ignorado se não tiver barras suficientes para satisfazer a opção -pnum ou --strip=num. O nome /dev/null também é ignorado.
Se houver uma linha "Index:" no "lixo" inicial e se os nomes antigo e novo estiverem ausentes ou se o patch estiver em conformidade com o POSIX, o patch pega o nome na linha "Index:".
Para fins das seguintes regras, os nomes de arquivo candidatos são considerados na ordem (antigo, novo, índice), independentemente da ordem em que aparecem no cabeçalho.
Em seguida, o patch seleciona um nome de arquivo da lista de candidatos da seguinte forma:
Se alguns dos arquivos nomeados existirem, o patch seleciona o primeiro nome se estiver em conformidade com o POSIX e o melhor nome caso contrário.
Se o patch não estiver ignorando RCS, ClearCase, Perforce e SCCS (consulte a opção -g num ou --get=num) e nenhum dos arquivos nomeados existir, mas um mestre RCS, ClearCase, Perforce ou SCCS for encontrado, o patch seleciona o primeiro nome de arquivo com um mestre RCS, ClearCase, Perforce ou SCCS.
Se nenhum arquivo nomeado existir, nenhum mestre RCS, ClearCase, Perforce ou SCCS for encontrado, alguns nomes forem fornecidos, o patch não estiver em conformidade com o POSIX e o patch parecer criar um arquivo, o patch seleciona o melhor nome que requer a criação do menor número de diretórios.
Se nenhum nome de arquivo resultar das heurísticas acima, você será solicitado a fornecer o nome do arquivo a ser corrigido, e patch selecionará esse nome.
Para determinar o melhor de uma lista não vazia de nomes de arquivos, patch primeiro seleciona todos os nomes com o menor número de componentes de caminho; dentre esses, seleciona todos os nomes com o menor nome base; dentre esses, seleciona todos os nomes mais curtos; finalmente, seleciona o primeiro nome restante.
Além disso, se o cabeçalho contiver uma linha Prereq:, patch seleciona a primeira palavra da linha de pré-requisitos (normalmente um número de versão) e verifica o arquivo original para ver se essa palavra pode ser encontrada. Se não, patch solicita confirmação antes de prosseguir.
O resultado de tudo isso é que você deve ser capaz de executar algo como o seguinte comando de shell:
patch -d /usr/src/local/blurfl
e aplicar um arquivo de patch no diretório `blurfl` diretamente de um patch que é lido da entrada padrão.
Se o arquivo de patch contiver mais de um patch, patch tenta aplicar cada um deles como se viessem de arquivos de patch separados. Isso significa, entre outras coisas, que se assume que o nome do arquivo a ser corrigido deve ser determinado para cada listagem de diferenças e que o cabeçalho antes de cada listagem de diferenças contém coisas interessantes, como nomes de arquivos e nível de revisão, conforme mencionado anteriormente.
OPÇÕES
-b ou --backup
Cria arquivos de backup. Ou seja, quando corrige um arquivo, renomeia ou copia o arquivo original em vez de removê-lo. Consulte a opção -V ou --version-control para obter detalhes sobre como os nomes dos arquivos de backup são determinados.
--backup-if-mismatch
Faz backup de um arquivo se o patch não corresponder exatamente ao arquivo e se os backups não forem solicitados de outra forma. Esta é a configuração padrão, a menos que `patch` esteja em conformidade com o POSIX.
--no-backup-if-mismatch
Não faz backup de um arquivo se o patch não corresponder exatamente ao arquivo e se os backups não forem solicitados de outra forma. Esta é a configuração padrão se `patch` estiver em conformidade com o POSIX.
-B pref ou --prefix=pref
Usa o método simples para determinar os nomes dos arquivos de backup (consulte a opção -V ou --version-control) e anexa `pref` a um nome de arquivo ao gerar seu nome de arquivo de backup. Por exemplo, com -B /junk/, o nome do arquivo de backup simples para `src/patch/util.c` é `/junk/src/patch/util.c`.
--binary
Grava todos os arquivos no modo binário, exceto a saída padrão e `/dev/tty`. Ao ler, desativa a heurística para transformar quebras de linha CRLF em quebras de linha LF. Esta opção é necessária em sistemas POSIX ao aplicar patches gerados em sistemas não POSIX a arquivos não POSIX. (Em sistemas POSIX, as leituras e gravações de arquivos nunca transformam as quebras de linha. No Windows, as leituras e gravações transformam as quebras de linha por padrão e os patches devem ser gerados com `diff --binary` quando as quebras de linha são significativas.)
-c ou --context
Interpreta o arquivo de patch como um diff de contexto normal.
-d dir ou --directory=dir
Altera para o diretório `dir` imediatamente, antes de fazer qualquer outra coisa.
-D define ou --ifdef=define
Usar a construção #ifdef ... #endif para marcar alterações, tendo define como símbolo diferenciador.
--dry-run
Exibir os resultados da aplicação dos patches sem alterar nenhum arquivo de fato.
-e ou --ed
Interpretar o arquivo de patch como um script ed.
-E ou --remove-empty-files
Remover arquivos de saída que ficarem vazios após a aplicação dos patches. Normalmente esta opção é desnecessária, pois o patch pode examinar os carimbos de data/hora no cabeçalho para determinar se um arquivo deve existir após a aplicação do patch. No entanto, se a entrada não for um diff de contexto ou se o patch estiver em conformidade com o POSIX, o patch não remove arquivos patchados vazios, a menos que esta opção seja fornecida. Quando o patch remove um arquivo, ele também tenta remover quaisquer diretórios ancestrais vazios.
-f ou --force
Presumir que o usuário sabe exatamente o que está fazendo e não fazer perguntas. Pular patches cujos cabeçalhos não dizem qual arquivo deve ser patchado; patch arquivos mesmo que tenham a versão errada para a linha Prereq: no patch; e presumir que os patches não estão invertidos, mesmo que pareçam estar. Esta opção não suprime comentários; use -s para isso.
-F num ou --fuzz=num
Definir o fator de imprecisão máximo. Esta opção se aplica apenas a diffs que têm contexto e faz com que o patch ignore até essa quantidade de linhas de contexto ao procurar lugares para instalar um trecho. Note que um fator de imprecisão maior aumenta as chances de um patch defeituoso. O fator de imprecisão padrão é 2. Um fator de imprecisão maior ou igual ao número de linhas de contexto no diff de contexto, normalmente 3, ignora todo o contexto.
-g num ou --get=num
Esta opção controla as ações do patch quando um arquivo está sob controle do RCS ou SCCS, e não existe ou é somente leitura e corresponde à versão padrão, ou quando um arquivo está sob controle do ClearCase ou Perforce e não existe. Se num for positivo, o patch obtém (ou faz checkout) do arquivo do sistema de controle de revisão; se for zero, o patch ignora RCS, ClearCase, Perforce e SCCS e não obtém o arquivo; e se for negativo, o patch pergunta ao usuário se deseja obter o arquivo. O valor padrão desta opção é dado pelo valor da variável de ambiente PATCH_GET, se estiver definida; se não, o valor padrão é zero.
--help
Exibir um resumo das opções e sair.
-i arquivo_patch ou --input=arquivo_patch
Ler o patch do arquivo_patch. Se arquivo_patch for -, ler da entrada padrão, o padrão.
-l ou --ignore-whitespace
Corresponder padrões de forma flexível, caso tabulações ou espaços tenham sido alterados em seus arquivos. Qualquer sequência de um ou mais espaços no arquivo de patch corresponde a qualquer sequência no arquivo original, e sequências de espaços nos finais das linhas são ignoradas. Caracteres normais ainda devem corresponder exatamente. Cada linha do contexto ainda deve corresponder a uma linha no arquivo original.
--merge ou --merge=merge ou --merge=diff3
Mesclar um arquivo de patch nos arquivos originais de forma similar ao diff3(1) ou merge(1). Se um conflito for encontrado, o patch emite um aviso e delimita o conflito com linhas <<<<<<< e >>>>>>>. Um conflito típico terá esta aparência:
<<<<<<<
linhas do arquivo original
|||||||
linhas originais do patch
=======
novas linhas do patch
>>>>>>>
A opção opcional de --merge determina o formato de saída para conflitos: o formato diff3 mostra a seção ||||||| com as linhas originais do patch; no formato merge, esta seção está ausente. O formato merge é o padrão.
Esta opção implica --forward e não leva em consideração a opção --fuzz=num.
-n ou --normal
Interprete o arquivo de patch como um diff normal.
-N ou --forward
Quando um patch não é aplicado, o patch geralmente verifica se o patch parece ter sido aplicado
antes, tentando reverter a aplicação do primeiro bloco. A opção --forward impede isso. Veja
também -R.
-o outfile ou --output=outfile
Envie a saída para outfile em vez de aplicar patches nos arquivos no local. Não use esta opção se outfile
for um dos arquivos a serem corrigidos. Quando outfile é -, envie a saída para a saída padrão e
envie quaisquer mensagens que normalmente seriam enviadas para a saída padrão para o erro padrão.
-pnum ou --strip=num
Remova o menor prefixo contendo num barras iniciais de cada nome de arquivo encontrado no
arquivo de patch. Uma sequência de um ou mais barras adjacentes é contada como uma única barra. Isso
controla como os nomes de arquivo encontrados no arquivo de patch são tratados, caso você mantenha seus arquivos em um
diretório diferente da pessoa que enviou o patch. Por exemplo, supondo que o arquivo
nome no arquivo de patch foi
/u/howard/src/blurfl/blurfl.c
definir -p0 fornece o nome do arquivo completo inalterado, -p1 fornece
u/howard/src/blurfl/blurfl.c
sem a barra inicial, -p4 fornece
blurfl/blurfl.c
e não especificar -p fornece apenas blurfl.c. O que quer que você use, será procurado no diretório atual ou no diretório especificado pela opção -d.
--posix
Conforme-se mais estritamente com o padrão POSIX, conforme se segue.
Pegue o primeiro arquivo existente da lista (antigo, novo, índice) ao inferir nomes de arquivos dos
cabeçalhos diff.
Não remova arquivos que estejam vazios após a aplicação do patch.
Não pergunte se deve obter arquivos do RCS, ClearCase, Perforce ou SCCS.
Exija que todas as opções precedam os arquivos na linha de comando.
Não faça backup de arquivos quando houver uma incompatibilidade.
--quoting-style=word
Use o estilo word para citar nomes de saída. A palavra deve ser uma das seguintes:
literal
Saída dos nomes como estão.
shell
Cite os nomes para o shell se eles contiverem metacaracteres do shell ou causarem saída ambígua.
shell-always
Cite os nomes para o shell, mesmo que normalmente não precisem ser citados.
c
Cite os nomes como para uma string da linguagem C.
escape
Cite como com c, exceto omita os caracteres de aspas duplas circundantes.
Você pode especificar o valor padrão da opção --quoting-style com a variável de ambiente QUOTING_STYLE. Se essa variável de ambiente não estiver definida, o valor padrão é shell.
-r rejectfile ou --reject-file=rejectfile
Coloque as rejeições em rejectfile em vez do arquivo .rej padrão. Quando rejectfile é -, descarte as rejeições.
-R ou --reverse
Assuma que este patch foi criado com os arquivos antigo e novo invertidos. (Sim, tenho medo que isso aconteça ocasionalmente, sendo a natureza humana o que é.) patch tenta inverter cada bloco antes de aplicá-lo. As rejeições são geradas no formato invertido. A opção -R não funciona com scripts de diff ed, pois há pouca informação para reconstruir a operação inversa.
Se o primeiro bloco de um patch falhar, patch inverte o bloco para ver se ele pode ser aplicado dessa forma. Se puder, você será solicitado a definir a opção -R. Se não puder, o patch continua a ser aplicado normalmente. (Observação: este método não pode detectar um patch invertido se for um diff normal e se o primeiro comando for um acréscimo (ou seja, deveria ter sido uma exclusão), já que os acréscimos sempre têm sucesso, devido ao fato de que um contexto nulo corresponde a qualquer lugar. Felizmente, a maioria dos patches adiciona ou modifica linhas, em vez de excluí-las, então a maioria dos diffs normais invertidos começa com uma exclusão, o que falha, acionando a heurística.)
--read-only=comportamento
Comporte-se conforme solicitado ao tentar modificar um arquivo somente leitura: ignore o problema potencial, avise sobre ele (o padrão) ou falhe.
--reject-format=formato
Gere arquivos de rejeição no formato especificado (contexto ou unificado). Sem esta opção, os blocos rejeitados são gerados no formato de diff unificado se o patch de entrada estiver nesse formato; caso contrário, no formato de diff de contexto normal.
-s ou --silent ou --quiet
Trabalhe em silêncio, a menos que ocorra um erro.
--follow-symlinks
Ao procurar arquivos de entrada, siga os links simbólicos. Substitua os links simbólicos, em vez de modificar os arquivos para os quais os links simbólicos apontam. Os patches no estilo Git para links simbólicos não serão mais aplicados. Esta opção existe para compatibilidade com versões anteriores do patch; seu uso é desencorajado.
-t ou --batch
Suprima perguntas como -f, mas faça algumas suposições diferentes: ignore os patches cujos cabeçalhos não contêm nomes de arquivos (o mesmo que -f); ignore os patches para os quais o arquivo tem a versão errada para a linha Prereq: no patch; e assuma que os patches estão invertidos se parecerem estar.
-T ou --set-time
Defina os horários de modificação e acesso dos arquivos modificados a partir dos carimbos de data/hora fornecidos nos cabeçalhos do diff de contexto. A menos que especificado nos carimbos de data/hora, assuma que os cabeçalhos do diff de contexto usam o horário local.
O uso desta opção com carimbos de data/hora que não incluem fusos horários não é recomendado, porque os patches que usam o horário local não podem ser facilmente usados por pessoas em outros fusos horários e porque os carimbos de data/hora locais são ambíguos quando os relógios locais são ajustados para trás durante os ajustes do horário de verão. Certifique-se de que os carimbos de data/hora incluam fusos horários ou gere patches com UTC e use a opção -Z ou --set-utc em vez disso.
-u ou --unified
Interpreta o arquivo de patch como um diff de contexto unificado.
-v ou --version
Imprime o cabeçalho de revisão e o nível do patch e sai.
-V method ou --version-control=method
Use method para determinar os nomes dos arquivos de backup. O método também pode ser especificado pela variável de ambiente PATCH_VERSION_CONTROL (ou, se esta não estiver definida, pela variável de ambiente VERSION_CONTROL), que é substituída por esta opção. O método não afeta se os arquivos de backup são criados; afeta apenas os nomes de quaisquer arquivos de backup que sejam criados.
O valor de method é semelhante à variável version-control do GNU Emacs; patch também reconhece sinônimos que são mais descritivos. Os valores válidos para method são (abreviações únicas são aceitas):
existing ou nil
Cria backups numerados dos arquivos que já os possuem, caso contrário, cria backups simples. Esta é a opção padrão.
numbered ou t
Cria backups numerados. O nome do arquivo de backup numerado para F é F.~N~, onde N é o número da versão.
simple ou never
Cria backups simples. As opções -B ou --prefix, -Y ou --basename-prefix e -z ou --suffix especificam o nome do arquivo de backup simples. Se nenhuma dessas opções for fornecida, um sufixo de backup simples é usado; este é o valor da variável de ambiente SIMPLE_BACKUP_SUFFIX, se definida, e é .orig caso contrário.
Com backups numerados ou simples, se o nome do arquivo de backup for muito longo, o sufixo de backup ~ é usado em vez disso; se até mesmo adicionar ~ tornar o nome muito longo, então ~ substitui o último caractere do nome do arquivo.
--verbose
Imprime informações adicionais sobre o trabalho que está sendo realizado.
-x num ou --debug=num
Define os flags de depuração internos de interesse apenas para os desenvolvedores do patch.
-Y pref ou --basename-prefix=pref
Usa o método simple para determinar os nomes dos arquivos de backup (veja a opção -V method ou --version-control method) e prefixa pref ao nome base de um arquivo ao gerar seu nome de arquivo de backup. Por exemplo, com -Y .del/ o nome do arquivo de backup simples para src/patch/util.c é src/patch/.del/util.c.
-z suffix ou --suffix=suffix
Usa o método simple para determinar os nomes dos arquivos de backup (veja a opção -V method ou --version-control method) e usa suffix como o sufixo. Por exemplo, com -z - o nome do arquivo de backup para src/patch/util.c é src/patch/util.c-.
-Z ou --set-utc
Define os horários de modificação e acesso dos arquivos corrigidos a partir das informações de data e hora fornecidas nos cabeçalhos do diff de contexto. A menos que especificado nas informações de data e hora, assume-se que os cabeçalhos do diff de contexto usam o Tempo Universal Coordenado (UTC, frequentemente conhecido como GMT). Veja também a opção -T ou --set-time.
As opções -Z ou --set-utc e -T ou --set-time normalmente se abstêm de definir a hora de um arquivo se a hora original do arquivo não corresponder à hora fornecida no cabeçalho do patch, ou se seu conteúdo não corresponder exatamente ao patch. No entanto, se a opção -f ou --force for fornecida, a hora do arquivo é definida, independentemente disso.
Devido às limitações do formato de saída diff, estas opções não podem atualizar os horários dos arquivos cujos conteúdos não foram alterados. Além disso, se você usar essas opções, deverá remover (por exemplo, com make clean) todos os arquivos que dependem dos arquivos que foram modificados, para que as invocações subsequentes de make não se confundam com os horários dos arquivos modificados.
AMBIENTE
PATCH_GET
Especifica se o patch obtém arquivos ausentes ou somente leitura de RCS, ClearCase, Perforce ou SCCS por padrão; veja a opção -g ou --get.
POSIXLY_CORRECT
Se estiver definido, o patch está em maior conformidade com o padrão POSIX por padrão; veja a opção --posix.
QUOTING_STYLE
Valor padrão da opção --quoting-style.
SIMPLE_BACKUP_SUFFIX
Extensão a ser usada para nomes de arquivos de backup simples em vez de .orig.
TMPDIR, TMP, TEMP
Diretório para colocar arquivos temporários; o patch usa a primeira variável de ambiente nesta lista que estiver definida. Se nenhuma estiver definida, o padrão é dependente do sistema; normalmente é /tmp em hosts Unix.
VERSION_CONTROL ou PATCH_VERSION_CONTROL
Seleciona o estilo de controle de versão; veja a opção -v ou --version-control.
ARQUIVOS
$TMPDIR/p*
arquivos temporários
/dev/tty
terminal de controle; usado para obter respostas para perguntas feitas ao usuário
VEJA TAMBÉM
diff(1), ed(1), merge(1).
Marshall T. Rose e Einar A. Stefferud, Proposed Standard for Message Encapsulation, Internet RFC 934 [https://datatracker.ietf.org/doc/html/rfc934] (1985-01).
NOTAS PARA ENVIADORES DE PATCHES
Há várias coisas que você deve ter em mente se for enviar patches.
Crie seu patch de forma sistemática. Ao usar um sistema de controle de versão, isso deve ser fácil; por exemplo, com Git, você pode usar git diff. Caso contrário, um bom método é o comando diff -Naur old new, onde old e new identificam os diretórios antigo e novo. Os nomes old e new não devem conter barras.
Se o patch deve comunicar os horários dos arquivos, bem como o conteúdo dos arquivos, os cabeçalhos dos comandos diff devem ter datas e horários em Tempo Universal usando o formato Unix tradicional, para que os destinatários do patch possam usar a opção -Z ou --set-utc. Aqui está um exemplo de comando para gerar esses cabeçalhos, usando a sintaxe do shell Bourne:
LC_ALL=C TZ=UTC0 diff -Naur myprog-2.7 myprog-2.8
Informe aos seus destinatários como aplicar o patch, dizendo-lhes para qual diretório ir (cd) e quais opções de patch usar. A string de opções -Np1 é recomendada. Teste seu procedimento fingindo ser um destinatário e aplicando seu patch a uma cópia dos arquivos originais.
Você pode evitar muitos problemas das pessoas mantendo um arquivo patchlevel.h que é modificado para incrementar o nível do patch como a primeira diferença no arquivo de patch que você enviar. Se você colocar uma linha Prereq: com o patch, ele não permitirá que eles apliquem patches fora de ordem sem algum aviso.
Você pode criar um arquivo enviando uma diferença que compara /dev/null ou um arquivo vazio datado da Era Comum (1970-01-01 00:00:00 UTC) com o arquivo que você deseja criar. Isso só funciona se o arquivo que você deseja criar já não existir no diretório de destino. Inversamente, você pode remover um arquivo enviando uma diferença de contexto que compara o arquivo a ser excluído com um arquivo vazio datado da Era Comum. O arquivo será removido, a menos que o patch seja conforme com o POSIX e a opção -E ou --remove-empty-files não seja fornecida. Uma maneira fácil de gerar patches que criam e removem arquivos é usar a opção -N ou --new-file do GNU diff.
Se o destinatário deve usar a opção -pN, não envie uma saída que se pareça com isso:
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
porque os dois nomes de arquivo têm um número diferente de barras e diferentes versões do patch interpretam os nomes dos arquivos de maneira diferente. Para evitar confusão, envie uma saída que se pareça com isso:
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
Evite enviar patches que comparem nomes de arquivos de backup como README.orig, pois isso pode confundir o patch e fazer com que ele aplique o patch em um arquivo de backup em vez do arquivo real. Em vez disso, envie patches que comparem os mesmos nomes de arquivos base em diretórios diferentes, por exemplo, old/README e new/README.
Tenha cuidado para não enviar patches invertidos, pois isso faz com que as pessoas se perguntem se elas já aplicaram o patch.
Tente não ter seu patch modificando arquivos derivados (por exemplo, o arquivo configure onde há uma linha configure: configure.ac em seu arquivo Makefile), pois o destinatário deve conseguir regenerar os arquivos derivados de qualquer maneira. Se você precisar enviar diferenças de arquivos derivados, gere as diferenças usando UTC, peça aos destinatários para aplicar o patch com a opção -Z ou --set-utc e peça a eles para remover quaisquer arquivos não aplicados que dependam de arquivos com patch (por exemplo, com make clean).
Embora você possa conseguir colocar 582 listagens de diferenças em um único arquivo, pode ser mais sensato agrupar patches relacionados em arquivos separados, caso algo dê errado.
DIAGNÓSTICOS
Os diagnósticos geralmente indicam que o patch não conseguiu analisar seu arquivo de patch.
Se a opção --verbose for fornecida, a mensagem Hmm... indica que há texto não processado no arquivo de patch e que o patch está tentando descobrir se há um patch nesse texto e, em caso afirmativo, que tipo de patch é.
O status de saída do patch é 0 se todos os blocos forem aplicados com sucesso, 1 se alguns blocos não puderem ser aplicados ou houver conflitos de mesclagem e 2 se houver um problema mais sério. Ao aplicar um conjunto de patches em um loop, é importante verificar esse status de saída para que você não aplique um patch posterior a um arquivo parcialmente com patch.
RESSALVAS
Diferenças de contexto não podem representar de forma confiável a criação ou exclusão de arquivos vazios, diretórios vazios ou arquivos especiais, como links simbólicos. Nem podem representar alterações no metadados do arquivo, como propriedade, permissões ou se um arquivo é um link físico para outro. Se alterações como estas também forem necessárias, instruções separadas (por exemplo, um script shell) para realizá-las devem acompanhar o patch.
o comando `patch` não consegue verificar se os números de linha estão incorretos em um script `ed`, e só pode detectar números de linha incorretos em um `diff` normal quando encontra uma alteração ou exclusão. Um `diff` de contexto usando um fator de "fuzz" de 3 pode ter o mesmo problema. Nesses casos, você provavelmente deve fazer um `diff` de contexto para verificar se as alterações foram significativas. Claro, compilar sem erros é uma boa indicação de que o patch funcionou, mas nem sempre.
Normalmente, o comando `patch` produz os resultados corretos, mesmo quando precisa fazer muitas suposições. No entanto, os resultados são garantidamente corretos apenas quando o patch é aplicado à versão exata do arquivo da qual o patch foi gerado.
PROBLEMAS DE COMPATIBILIDADE
O padrão POSIX especifica um comportamento diferente do GNU patch.
No patch POSIX, quando a opção -b não é usada, os backups não são criados, mesmo quando há uma incompatibilidade. No GNU patch, esse comportamento é ativado com a opção --no-backup-if-mismatch ou conformando-se com o POSIX usando a opção --posix ou definindo a variável de ambiente POSIXLY_CORRECT.
Ao inferir o nome do arquivo a ser corrigido a partir do cabeçalho do patch, o comando patch usa um método complicado que é opcionalmente compatível com o POSIX. O método é equivalente ao POSIX se os nomes dos arquivos no cabeçalho do diff de contexto e na linha Index: forem todos idênticos após a remoção dos prefixos. Seu patch é normalmente compatível se os nomes de arquivo em cada cabeçalho contiverem o mesmo número de barras.
Limite-se às seguintes opções ao enviar instruções que devem ser executadas por qualquer pessoa que use o GNU patch ou um patch que esteja em conformidade com o POSIX. Os espaços são opcionais na lista a seguir.
-b
-c
-d dir
-D define
-e
-i patchfile
-l
-n
-N
-o outfile
-p num
-R
-r rejectfile
-u
ERROS
Por favor, reporte os erros por e-mail para <_>.
Se o código foi duplicado (por exemplo, com #ifdef OLDCODE ... #else ... #endif), o comando patch não consegue corrigir ambas as versões e, se funcionar, provavelmente corrigirá a versão errada e dirá que teve sucesso.
Se você aplicar um patch que já aplicou, o comando patch acha que é um patch reverso e oferece desfazer o patch. Isso pode ser considerado um recurso.
Calcular como mesclar um bloco é significativamente mais difícil do que usar o algoritmo de "fuzz" padrão. Blocos maiores, mais contexto, um deslocamento maior da localização original e uma correspondência pior tornam o algoritmo mais lento.
DIREITOS AUTORAIS
Copyright © 1989–2025 Free Software Foundation, Inc. Copyright © 1984–1986, 1988 Larry Wall.
É concedido o direito de fazer e distribuir cópias literais deste manual, desde que o aviso de direitos autorais e este aviso de permissão sejam preservados em todas as cópias.
É concedida permissão para copiar e distribuir versões modificadas deste manual sob as condições para cópia literal, desde que todo o trabalho derivado resultante seja distribuído sob os termos de um aviso de permissão idêntico a este.
É concedida permissão para copiar e distribuir traduções deste manual para outro idioma, sob as condições acima para versões modificadas, exceto que este aviso de permissão pode ser incluído em traduções aprovadas pelos detentores dos direitos autorais em vez de no inglês original.
AUTORES
Larry Wall escreveu a versão original do patch. Paul Eggert removeu os limites arbitrários do patch; adicionou suporte para arquivos binários, definição de horários de arquivos e exclusão de arquivos; e fez com que ele estivesse mais em conformidade com o POSIX. Outros colaboradores incluem Wayne Davison, que adicionou suporte para unidiff, e David MacKenzie, que adicionou suporte para configuração e backup. Andreas Gruenbacher adicionou suporte para mesclagem.