EN JA
PATCH(1)
PATCH(1) FreeBSD General Commands Manual PATCH(1)

名称

patchオリジナルのファイルに diff ファイルを適用する

書式

patch [ -bCcEeflNnRstuv][ -B  backup-prefix][ -D  symbol][ -d  directory][ -F  max-fuzz][ -i  patchfile][ -o  out-file][ -p  strip-count][ -r  rej-name][ -V  t |  nil |  never][ -x  number][ -z  backup-ext][ --posix][ origfile [ patchfile]]

patch < patchfile

解説

patch は、 diff(1) プログラムによって生成さたれ差分リストの 4 つの形式のいずれかを含むパッチファイルを取り、オリジナルのファイルに、それらの差分を適用して、パッチされたバージョンを生成します。 patchfile が省略されるか、またはハイフンであるなら、パッチは、標準入力から読み込まれます。

patch は、 -c, -e, -n または -u オプションによって覆されないなら、差分リストのタイプを決定することを試みます。 ed diff が、単にパイプによって ed(1) エディタに送り込まれるのに対して、コンテキスト (context) diff (古いスタイル、新しいスタイルとユニファイド (unified)) と通常の diff は、 patch プログラム自体によって直接適用されます。

patchfile が 2 つ以上のパッチを含んでいるなら、 patch は、あたかもそれらが個別のパッチファイルであるかのように、それらの各々を適用しようと試みます。これは、とりわけ、パッチするファイルの名前が各差分リストに対して決定されなければならないと仮定され、各差分リストの前のゴミがファイル名とリビジョンレベル (下記の ファイル名の決定 のセクションを参照) のような興味深いものについて検査されることを意味します。

オプションは、次の通りです:

-B backup-prefix, - -prefix backup-prefix
次の引数は、バックアップファイル名の接頭辞として解釈されます。この引数が指定されるなら、 -z へのあらゆる引数は、無視されます。
-b, - -backup
ファイルが修正される前に、ファイルのバックアップのコピーを保存します。デフォルトで、オリジナルのファイルは、ファイルにまだ番号が付けられたバックアップがないなら、“.orig”のバックアップの拡張子で保存されます、既に番号が付けられたバックアップがある場合に、番号が付けられたバックアップが作られます。これは、“ -V existing”を指定すること同等です。このオプションは、現在、 --posix が指定されないなら、デフォルトです。
-C, - -check
パッチがきっちり適用されることをチェックしますが、何も修正しません。
-c, - -context
patch は、強制的にコンテキスト diff としてパッチファイルを解釈します。
-D symbol, - -ifdef symbol
patch は、変更をマークするために“#ifdef...#endif”構成を使用します。続く引数は、識別するシンボルとして使用されます。 C コンパイラと異なり、 -D と引数の間に空白がなければならないことに注意してください。
-d directory, - -directory directory
patch は、ディレクトリとして次の引数を解釈し、ほかに何かを行う前に、作業ディレクトリをそれに変更します。
-E, - -remove-empty-files
patch は、パッチが適用された後に、空の出力ファイルを削除します。このオプションは、ファイルを作成するか、または削除するパッチを適用するとき、役に立ちます。
-e, - -ed
patch は、強制的に ed(1) スクリプトとしてパッチファイルを解釈します。
-F max-fuzz, - -fuzz max-fuzz
最大の fuzz (曖昧) 因子を設定します。このオプションは、コンテキスト diff にのみ適用し、 patch は、hunk を導入する場所を捜す多くの行まで無視します。より大きな fuzz 因子は、不完全なパッチの可能性を増加させることに注意してください。デフォルトの fuzz 因子は、2 であり、通常 3 のコンテキスト diff のコンテキストの行数を越えるように設定されません。
-f, - -force
patch は、強制的にユーザが何を行っているか正確に知っていると仮定し、どんな質問も問い合わせません。次のように仮定します: パッチを行うファイルを見つけることができないパッチをスキップします。パッチの“Prereq:”行に対して間違ったバージョンがあったとしても、ファイルをパッチします。そして、リバース (逆の) パッチのように思われても、パッチがリバースパッチでないと仮定します。このオプションは、エラーメッセージを抑制しません。そのためには、 -s を使用します。
-i patchfile, - -input patchfile
次の引数を入力ファイル名 (すなわち、パッチファイル) として解釈します。このオプションを、複数回指定することができます。
-l, - -ignore-whitespace
タブとスペースが入力ファイルで復元できないほと変更された場合に、パターンマッチングは、緩く行われます。パターン行の空白類のあらゆるシーケンスは、入力ファイルのあらゆる空白類のシーケンスに一致します。通常の文字は、それでも正確に一致しなければなりません。コンテキストの各行は、それでも入力ファイルの行と一致しなければなりません。
-N, - -forward
patch は、リバースパッチまたは既に適用されていると思われるパッチを強制的に無視します。 -R も参照してください。
-n, - -normal
patch は、強制的に通常の diff としてパッチファイルを解釈します。
-o out-file, - -output out-file
次の引数は、出力ファイル名として解釈されます。
-p strip-count, - -strip strip-count
パッチを送った人とは異なるディレクトリにファイルを保持しているた場合に、パッチファイルに見つかるパス名をどのように扱うかを制御するパス名を取り除く (ストリップ) カウントを設定します。取り除く (ストリップ) カウントは、どれだけのスラッシュがパス名の前から取り除かれるかを指定します。 (途中にある、あらゆるディレクトリ名も取り除かれます。) 例えば、パッチファイルのファイル名が、 /u/howard/src/blurfl/blurfl.c であったなら:

-p0 と設定することは、すべてのパス名が変更されません。

-p1 は、先導するスラッシュのない

u/howard/src/blurfl/blurfl.c

となります。

-p4 は、

blurfl/blurfl.c

となります。先導するパス ( u/howard/src/blurfl) 中のディレクトリのすべてが存在して、パスが相対的である場合 (その場合に、すべてのパス名は、変更されないこととなります) を除いて、 -p をまったく指定しないことは、 blurfl.c となります。終わりのファイルは、なんでも、カレントディレクトリまたは -d オプションによって指定されたディレクトリのいずれかで検索されます。

-R, - -reverse
このパッチは、古いファイルと新しいファイルを交換して作られたパッチであることを patch に伝えます。 (はい、時々そのようなことが起こると思われます、人間性とは、そういうものです。) patch は、それを適用する前に、各 hunk を交換することを試みます。リジェクト (reject) ファイルは、交換された形式で作成されます。 -R オプションは、リバース操作を再構成する情報があまりにも少ないので、 ed diff スクリプトで動作しません。

パッチの最初の hunk が失敗するなら、 patch は、リバース (逆に) する方法を適用することができるかどうか調べるために hunk を逆にします。できるるなら、 -R オプションを設定したいかどうか問い合わされます。できないなら、通常、パッチは、適用され続けます。 (注: この方法は、常に空のコンテキストがどんな場所でも一致するという事実のために、通常の diff であるなら、そして最初のコマンドが追加 (すなわち、削除であるべきだった) であるなら、追加は、常に後であるので、リバースパッチを検出することができません。幸いにも、ほとんどのパッチは、行を削除するのではなく、行を追加するかまたは変更するので、ほとんどのリバースの通常の diff は、削除で始まり、発見的に引き起こされて失敗します。)

-r rej-name, - -reject-file rej-name
次の引数は、リジェクトのファイル名として解釈されます。
-s, - -quiet, - -silent
patch は、エラーが起こらないなら、静かに作業を行います。
-t, - -batch
質問を抑制する点で、 -f に似ていますが、次のいくつかの異なる仮定を行います: パッチを見つけることができないファイルを ( -f と同様に) スキップします。パッチの“Prereq:”行に対して間違ったバージョンがあるファイルのパッチをスキップします。そして、リバース (逆の) パッチのように思われても、パッチがリバースパッチでないと仮定します。
-u, - -unified
patch は、強制的にユニファイドコンテキスト (unified context) diff (unidiff) としてパッチファイルを解釈します。
-V t | nil | never, - -version-control t | nil | never
次の引数は、バックアップファイル名を作成する方法として解釈されます。また、作られるバックアップのタイプは、このオプションによって上書きされる、 PATCH_VERSION_CONTROL または VERSION_CONTROL 環境変数で与えることができます。 -B オプションは、このオプションを上書きし、接頭辞は、バックアップファイル名を作るために常に使用されます。 PATCH_VERSION_CONTROLVERSION_CONTROL 環境変数の値と -V オプションへの引数は、GNU Emacs “version-control”変数に似ています。また、それらは、より記述的である同意語を認識します。有効な値は、次の通りです (ユニークな略語が受け付けられます):
t, numbered
常に番号が付けられたバックアップを行います。
nil, existing
既に番号が付けられたバックアップがあるファイルの番号が付けられたバックアップを行い、他のものの単純なバックアップを行います。
never, simple
常に単純なバックアップを行います。
-v, - -version
patch は、そのリビジョンヘッダとパッチレベルを印刷 (表示) します。
-x number, - -debug number
内部デバッグのフラグを設定します、 patch にパッチを当てる人のみ関心があるものです。
-z backup-ext, - -suffix backup-ext
次の引数は、“.orig”の代わりに使用されるバックアップの拡張子として解釈されます。
- -posix
特に、厳密な IEEE Std 1003.1-2008 (“POSIX.1”) 適合を有効にします:
  1. バックアップファイルは、 -b オプションが指定されなければ、作成されません。
  2. 指定されないなら、使用されるファイル名は、最初の存在する古くて、新しいインデックスファイルです。

パッチのアプリケーション

patch は、あらゆる先導するごみをスキップし、diff を適用し、次に、あらゆる後続すうrごみをスキップしようと試みます。したがって、 patch へ差分リストを含んでいる記事またはメッセージを送り込むことができ、それは、動作するべきです。すべての diff が一貫した量によって段付けされるなら、これは、考慮されます。

コンテキスト diff と、より少ない範囲の通常の diff で、 patch は、パッチ中に記述された行番号が正しくないとき、検出することができ、パッチの各 hunk を適用する正確な場所を見つけることを試みます。最初の推測として、hunk のために記述された行番号、前の hunk を適用するために使用されるプラスまたはマイナスのあらゆるオフセットを取ります。それが正確な場所でないなら、 patch は、hunk で与えられたコンテキストと一致する 1 組の行に対して前方または後方の両方をスキャンします。最初に patch は、コンテキストのすべての行が一致する場所を検索します。そのような場所が見つからず、コンテキスト diff であり、最大の fuzz 因子が 1 つ以上であるなら、コンテキストの最初と最後の行を無視して、別のスキャンが行われます。それが失敗し、最大の fuzz 因子が 2 つ以上に設定されるなら、コンテキストの最初の 2 行と最後の 2 行は、無視され、別のスキャンが行われます。 (デフォルト最大の fuzz 因子は、2 です。)

patch がパッチのその hunk をインストールする場所を見つけることができないなら、 hunk は、通常、出力ファイルに“.rej”が付けられた名前である、リジェクトファイルに出力されます。 (リジェクトされた hunk は、入力パッチがコンテキスト diff であろうと通常の diff であろうと、コンテキスト diff 形式で出力されることに注意してください。入力が通常の diff であったなら、コンテキストの多くは、単に空 (null) です。) リジェクトファイルの hunk の行番号は、次のパッチファイルとは異なります: それらは、古いものではなく新しいファイルに合っている失敗した hunk と考える近似の位置のパッチをリジェクトします。

各 hunk 完了するように、hunk が成功したか、または失敗したか、 (新しいファイルの) どの行の patch が hunk を処理すると考慮すべきかどうかを伝えられます。これが diff 中で指定された行番号と異なるなら、オフセットが伝えられます。単一大きなオフセットは、hunk が間違った場所に組み込まれたことを示すかもしれません。また、fuzz 因子が一致を行うために使用されるなら、伝えられ、その場合には、また、少し疑われます。

ファイル名の決定

オリジナルのファイルがコマンド行で指定されないなら、 patch は、編集するファイルの名前が何かを先導するなごみから見つけ出すように試みます。予想されるファイル名をチェックするとき、パス名の構成要素は、 -p オプションによって指定されるように取り除かれ、ファイルの存在と書き込み可能性は、現在の作業ディレクトリ (または -d オプションによって指定されたディレクトリ) と相対的であるかチェックされます。

diff がコンテキストまたはユニファイド (unified) diff であるなら、 patch は、差分ヘッダからの古いファイル名と新しいファイル名を決定することができます。コンテキスト diff について、“old” (古い) ファイルは、“***”で始まる行で指定され、“new” (新しい) ファイルは、“---”で始まる行で指定されます。ユニファイド (unified) diff について、“old” (古い) ファイルは、“---”で始まる行で指定され、“new” (新しい) ファイルは、“+++”で始まる行で指定されます。 (diff タイプにかかわらず) 先導するごみに“Index:”行があるなら、 patch は、“index”ファイルとしてその行からファイル名を使用します。

patch は、使用される最初の一致とともに、次のステップを実行することによってファイル名を選択します:

  1. patch が厳密な IEEE Std 1003.1-2008 (“POSIX.1”) モードで動作しているなら、存在する“old”, “new”と“index”ファイル名の最初が使用されます。そうでなければ、 patch は、“old”と“new”ファイル名または、コンテキスト diff については、“index”ファイル名を調査し、最も少ないパス構成要素があるファイル名、最も短いベース名 (basename) と最も短い合計ファイル名の長さ (この順序で) を選びます。
  2. ファイルが存在しないなら、 patch は、上記で指定された基準を使用する (適切な接頭辞または接尾辞を使用して) SCCS または RCS ディレクトリのファイルの存在をチェックします。見つかるなら、 patch は、ファイルを取得するかまたはチェックアウトすることを試みます。
  3. パッチする適切なファイルが見つからなかったなら、パッチファイルは、コンテキスト diff またはユニファイド diff であり、古いファイルは、0 の長さであり、新しいファイル名が作成され使用されます。
  4. まだファイル名を決定することができないなら、 patch は、使用するファイル名についてユーザにプロンプトを出します。

さらに、先導するごみが“Prereq: ”行を含んでいるなら、 patch は、必要条件 (prerequisites) の行 (通常、バージョン番号) から最初の単語を取り、その単語を見つけられることができるかどうか確かめるために入力ファイルをチェックします。そうでないなら、 patch は、続行する前に確認を求めます。

このすべての結末は、次の、news インタフェースで記述できるにはずです:

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

そして、パッチを含んでいる記事から blurfl ディレクトリのファイルに直接パッチします。

バックアップファイル

デフォルトで、パッチされたバージョンは、拡張子“.orig”がある同じ名前にバックアップされるか、または -B, -V または -z オプションによって指定されるオリジナルのファイルとともにオリジナルの代わりに置かれます。また、バックアップファイルを作るために使用される拡張子は、上記のオプションによって上書きされる SIMPLE_BACKUP_SUFFIX 環境変数で指定されます。

バックアップファイルがオリジナルのファイルにシンボリックリンクか、またはハードリンクされているなら、 patch は、ファイルの名の最後の構成要素の最初の小文字を大文字に変更することによって新しいバックアップファイル名を作成します。名前の中に小文字がないなら、名前から最初の文字を取り除きます。まだ存在していないか、またはオリジナルのファイルにリンクされていないバックアップファイルを見つけ出すまで、この処理を繰り返します。

また、利用者は、 -o オプションで出力が行われる場所を指定することができます。そのファイルが既に存在するなら、それは、最初にバックアップされます。

パッチの送信側のための注意

パッチを送信しようとしているなら、覚えておくべきことがいくつかあります:

最初に、送信するパッチファイル中の最初の diff としてパッチレベルを増加するためにパッチされる patchlevel.h ファイルを保持することによって多くのトラブルから人々を救います。パッチに“Prereq:”行を置くなら、いくつかの警告なしで適切でないパッチを適用しません。

2 番目に、コンテキスト diff ヘッダ、または“Index:”行のいずれかで指定されたファイル名が正しいことを確かめてください。サブディレクトリの何かをパッチしているなら、 -p オプションを指定するために必ずパッチユーザに伝えてください。

3 番目に、空ファイルと作成したいファイルと比較する diff を送信することによって、ファイルを作成することができます。これは、作成したいファイルがまだターゲットディレクトリに存在しないなら、単に動作します。

4 番目に、それらが既にパッチを適用したかどうか人々が不思議に思うので。リバースパッチを送信しないように注意してください。

5 番目に、1 つのファイルに 582 の差分リストを入れることを許されるかもしれませんが、何かがめちゃくちゃになった場合に、個別のファイルへ関連するパッチをグループ化するほうが、おそらく賢明です。

環境変数

POSIXLY_CORRECT
設定されるとき、 patch は、あたかも、 - -posix オプションが指定されたかのように振る舞います。
SIMPLE_BACKUP_SUFFIX
“.orig”の代わりにバックアップファイル名のために使用する拡張子。
TMPDIR
テンポラリファイルを置くディレクトリ。デフォルトは、 /tmp です。
PATCH_VERSION_CONTROL
番号が付けられたバックアップファイルが作られるとき、選択します。
VERSION_CONTROL
PATCH_VERSION_CONTROL と同様です。

関連ファイル

$TMPDIR/patch*
patch の一時ファイル
/dev/tty
patch がユーザにプロンプトを出すとき、入力を読み込むために使用します

終了ステータス

patch ユーティリティは、次の値の 1 つで終了します:

0
成功して完了。
1
1 つ以上の行がリジェクトファイルに書き込まれました。
>1
エラーが生じました。

ループ中の 1 組のパッチを適用するとき、この終了ステータスをチェックするために好都合ですので、部分的にパッチされたファイルに後のパッチを適用しません。

診断

あまりに多くをここでリストするために、 patch が利用者のパッチファイルを解析することを一般的に示します。

メッセージ“Hmm...”は、パッチファイル中の処理されていないテキストがあること、 patch が、そのテキスト中にパッチがあるかどうか直観で知ることを試みていること、そして、そうだとしたら、どんな種類のパッチであるかを示します。

関連項目

diff(1)

規格

patch ユーティリティは、 ( --posix オプションのために上記に述べられるものを除いて) IEEE Std 1003.1-2008 (“POSIX.1”) 仕様に準拠していますが、 patch 自体の存在は、オプションです。

フラグ[ -BCEFfstVvxz]と[ --posix]は、その仕様の拡張です。

作者

Larry Wall と他の多くの貢献者。

警告

patch は、行番号が ed スクリプトで外れているなら、伝えることができません、“change”または“delete”コマンドを見つけるとき、通常の diff の悪い行番号だけを検出することができます。 fuzz 因子 3 を使用するコンテキスト diff は、同じ問題があるかもしれません。適切な対話型のインタフェースが追加されるまで、変更が意味があるかどうか確かめるために、たぶん、これらの場合のコンテキスト diff を行うべきです。もちろん、エラーのないコンパイルは、パッチが動作したかをかなり良く示しますが、常にそうではありません。

patch は、多くの推測することを行わなければならないときでさえ、通常、正確な結果となります。しかしながら、結果は、パッチが生成されたファイルの同じバージョンに正確に適用されるときだけパッチが正確なことが保証されます。

バグ

部分的な一致、過度に逸脱したオフセットと交換されたコードに関してより賢くなる可能性がありますが、それは余分なパスを取るでしょう。

チェックパッチモード ( -C) は、互いに構築するいくつかの連続したパッチをチェックしようとするなら、失敗します。全体の patch コードは、この状況を扱うことができるように、一時ファイルをまわりを保持するために再構成されなければならないでしょう。

(例えば、#ifdef OLDCODE ... #else ... #endif で) コードが複写されているなら、 patch は、両方のバージョンをパッチすることができず、少し動作するなら、たぶん間違ったものをパッチし、おまけにそれが成功したと伝えます。

既に適用したパッチを適用するなら、 patch は、リバースパッチであると考えて、パッチを適用しないようにエラーを出します。これは、機能として解釈されるかもしれません。

January 29, 2013 FreeBSD