41.3 同期プロセスの作成

同期プロセス(synchronous process)の作成後、Emacsは継続する前にそのプロセスの終了を待機します。GNUやUnix29でのDiredの起動が例です。プロセスは同期的なので、Emacsがそれにたいして何か行おうと試みる前にディレクトリーのリスト全体がバッファーに到着します。

同期サブプロセス終了をEmacsが待機する間に、ユーザーはC-gをタイプすることでquitが可能です。最初のC-gSIGINTシグナルによりサブプロセスのkillを試みます。しかしこれはquitする前に実際にそのサブプロセスが終了されるまで待機します。その間にユーザーがさらにC-gをタイプするとそれはSIGKILLで即座にサブプロセスをkillしてquitします(別プロセスにたいするkillが機能しないMS-DOSを除く)。quitを参照してください。

同期サブプロセス関数はプロセスがどのように終了したかの識別をリターンします。

同期サブプロセスからの出力はファイルからのテキスト読み込みと同じように、一般的にはコーディングシステムを使用してデコードされます。call-process-regionによりサブプロセスに送信された入力は、ファイルへのテキスト書き込みと同じようにコーディングシステムを使用してエンコードされます。コーディングシステムを参照してください。

Function: call-process program &optional infile destination display &rest args

この関数はprogramを呼び出して完了するまで待機する。

サブプロセスのカレント作業ディレクトリー(CWD: current working directory)はカレントバッファーのdefault-directoryがローカル(unhandled-file-name-directoryにより判断される)ならその値、それ以外は"~"。リモートディレクトリーでプロセスを実行したければprocess-fileを使用すること。

新たなプロセスの標準入力はinfileが非nilならファイルinfile、それ以外ならnullデバイス。引数destinationはプロセスの出力をどこに送るかを指定する。以下は可能な値:

バッファー

そのバッファーのポイントの前に出力を挿入する。これにはプロセスの標準出力ストリームと標準エラーストリームの両方が含まれる。

バッファー名(文字列)

その名前のバッファーのポイントの前に出力を挿入する。

t

カレントバッファーのポイントの前に出力を挿入する。

nil

出力を破棄する。

0

出力を破棄してサブプロセス完了を待機せずに即座にnilをリターンする。

この場合にはプロセスはEmacsと並列に実行可能なので真に同期的ではない。しかしこの関数リターン後は本質的にはすみやかにEmacsがサブプロセスを終了するという点から、これを同期的と考えることができる。

MS-DOSは非同期サブプロセスをサポートせずこのオプションは機能しない。

(:file file-name)

指定されたファイルに出力を送信して、ファイルが既に存在すれば上書きする。

(real-destination error-destination)

標準出力ストリームを標準エラーストリームと分けて保持する。通常の出力はreal-destinationの指定にしたがって扱い、エラー出力はerror-destinationにしたがって処分する。error-destinationnilならエラー出力の破棄、tなら通常の出力と混合することを意味して、文字列ならそれはエラー出力をリダイレクトするファイルの名前である。

エラー出力先に直接バッファーを指定することはできない。ただしエラー出力を一時ファイルに送信して、サブプロセス終了時にそのファイルをバッファーに挿入すればこれを達成できる。

displayが非nilなら、call-processは出力の挿入にしたがってバッファーを再表示する(しかし出力のデコードに選択されたコーディングシステムが実データからエンコーディングを推論することを意味するundecidedなら、非ASCIIに一度遭遇すると再表示が継続不能になることがある。これを修正するのが困難な根本的理由が存在する。プロセスからの出力の受信を参照)。

それ以外なら関数call-processは再表示を行わずに、通常のイベントに由来するEmacsの再表示時だけスクリーン上で結果が可視になります。

残りの引数argsはそのプログラムにたいしてコマンドライン引数を指定する文字列です。文字列はそれぞれ別個の引数としてprogramに渡されます。

(待機するよう告げた場合には) call-processがリターンする値はプロセスが終了した理由を示します。この数字はそのサブプロセスのexitステータスであり0が成功、それ以外のすべての値は失敗を意味します。シグナルによりそのプロセスが終了された場合には、call-processはそれを記述する文字列をリターンします。call-processに待機しないように指示した場合にはnilをリターンします。

以下の例ではカレントバッファーは‘foo’です。

(call-process "pwd" nil t)
     ⇒ 0

---------- Buffer: foo ----------
/home/lewis/manual
---------- Buffer: foo ----------

(call-process "grep" nil "bar" nil "lewis" "/etc/passwd")
     ⇒ 0

---------- Buffer: bar ----------
lewis:x:1001:1001:Bil Lewis,,,,:/home/lewis:/bin/bash

---------- Buffer: bar ----------

以下はcall-processの使用例であり、このような使用例はinsert-directory関数の定義内で見つけることができます:

(call-process insert-directory-program nil t nil switches
              (if full-directory-p
                  (concat (file-name-as-directory file) ".")
                file))
Function: process-file program &optional infile buffer display &rest args

この関数は別プロセス内でファイルを同期的に処理する。これはcall-processと似ているが、サブプロセスのカレントワーキングディレクトリーを指定する変数default-directoryの値にもとづいて、ファイル名ハンドラーを呼び出すかもしれない。

引数はcall-processの場合とほとんど同様の方法で処理されるが以下の違いがある:

引数infilebufferdisplayのすべての組み合わせと形式をサポートしないファイル名ハンドラーがあるかもしれない。たとえば実際に渡された値とは無関係に、displaynilであるかのように振る舞うファイル名ハンドラーがいくつかある。他の例としてはbuffer引数で標準出力とエラー出力を分離するのをサポートしないかもしれないファイル名ハンドラーがいくつか存在する。

ファイル名ハンドラーが呼び出されると、1つ目の引数programにもとづいて実行するプログラムを決定する。たとえばリモートファイルにたいするハンドラーが呼び出されたと考えてみよ。その場合にはプログラムの検索に使用されるパスはexec-pathとは異なるかもしれない。

2つ目の引数infileはファイル名ハンドラーを呼び出すかもしれない。そのファイル名ハンドラーは、process-file関数自身にたいして選択されたハンドラーと異なるかもしれない(たとえばdefault-directoryがリモートホスト上にありinfileは別のリモートホスト上の場合があり得る。もしくはdefault-directoryは普通だがinfileはリモートホスト上にあるかもしれない).

buffer(real-destination error-destination)という形式のリストであり、かつerror-destinationがファイルの名前ならinfileと同じ注意が適用される。

残りの引数( args )はそのままプロセスに渡される。Emacsはargs内で与えられたファイル名の処理に関与しない。混乱を避けるためにはargs内で絶対ファイル名を使用しないのが最善であり、default-directoryからの相対ファイル名ですべてのファイルを指定するほうがよいだろう。そのような相対ファイル名の構築には関数file-relative-nameが有用。かわりにリモートホスト視点から見た絶対ファイル名を取得するためにfile-local-nameも使用できる(特定のファイル名の“Magic”の作成を参照)。

Variable: process-file-side-effects

この変数はprocess-file呼び出しがリモートファイルを変更するかどうかを示す。

この変数はデフォルトではprocess-file呼び出しがリモートホスト上の任意のファイルを潜在的に変更し得ることを意味するtに常にセットされる。nilにセットされた際には、リモートファイル属性のキャッシュにしたがうことによりファイル名ハンドラーの挙動を最適化できる可能性がある。

この変数は決してsetqではなく、常にletバインディングでのみ変更すること。

User Option: process-file-return-signal-string

このユーザーオプションは、リモートプロセスに割り込んだシグナルを記述する文字列をprocess-file呼び出しがリターンするかどうかを示す。

プロセスが128より大なexitコードをリターンしたら、それはシグナルとして解釈される。process-fileはこのシグナルを説明する文字列のリターンを求められる。

この規約に違反するプロセスが存在するために、シグナルにバインドされない128より大なexitコードのリターンでは、常にprocess-fileはリモートプロセスにたいする自然数としてexitコードをリターンする。このユーザーオプションを非nilにセットすることによって、そのようなexitコードをシグナルとして解釈して、それに対応する文字列をリターンするようにprocess-fileに強制することができる。

Function: call-process-region start end program &optional delete destination display &rest args

この関数はstartからendのテキストを、実行中のプロセスprogramに標準入力として送信する。これはdeleteが非nilなら送信したテキストを削除する。これは出力をカレントバッファーの入力箇所に挿入するために、destinationtに指定している際に有用。

引数destinationdisplayはサブロセスからの出力にたいして何を行うか、および出力の到着にともない表示を更新するかどうかを制御する。詳細は上述のcall-processの説明を参照のこと。destinationが整数の0ならcall-process-regionは出力を破棄して、サブプロセス完了を待機せずに即座にnilをリターンする(これは非同期サブプロセスがサポートされる場合、つまりMS-DOS以外でのみ機能する)。

残りの引数argsはそのプログラムにたいしてコマンドライン引数を指定する文字列です。

call-process-regionのリターン値はcall-processの場合と同様。待機せずにリターンするよう指示した場合にはnil、数字か文字列ならそれはサブプロセスが終了した方法を表す。

以下の例ではバッファー‘foo’内の最初の5文字(単語‘input’)を標準入力として、call-process-regionを使用してcatユーティリティを実行する。catは自身の標準入力を標準出力へコピーする。引数destinationtなので出力はカレントバッファーに挿入される。

---------- Buffer: foo ----------
input∗
---------- Buffer: foo ----------

(call-process-region 1 6 "cat" nil t)
     ⇒ 0

---------- Buffer: foo ----------
inputinput∗
---------- Buffer: foo ----------

たとえばshell-command-on-regionコマンドは、以下のような方法でcall-shell-regionを使用する:

(call-shell-region
 start end
 command              ; shellコマンド
 nil                  ; regionを削除しない
 buffer)              ; 出力をbufferに出力
Function: call-process-shell-command command &optional infile destination display

この関数はshellコマンドcommandを非同期に実行する。他の引数はcall-processの場合と同様に処理される。古い呼び出し規約はdisplayの後に任意個数の追加引数を許容して、これはcommandに結合される。これはまだサポートされるものの使用しないことを強く推奨する。

Function: process-file-shell-command command &optional infile destination display

この関数はcall-process-shell-commandと同様だが内部的にprocess-fileを使用する点が異なる。default-directoryに依存してcommandはリモートホスト上でも実行可能。古い呼び出し規約はdisplayの後に任意個数の追加引数を許容して、これはcommandに結合される。これはまだサポートされるものの使用しないことを強く推奨する。

Function: call-shell-region start end command &optional delete destination

この関数はstartendの間のテキストを、commandを実行するシェルの標準入力として送信する。これはプロセスがシェルであるようなcall-process-regionと類似している。引数deletedestination、およびリターン値はcall-process-regionと同様。この関数は追加の引数を受け付けないことに注意。

(shell-file-nameを通じて)commandがシェルを指定している場合には、コマンドがシェルの標準入力にpipeされた際の挙動はシェルごとにさまざまであり、システムにも依存するので可搬性がないことに留意すること。リージョンに複数行が含まれている場合、すなわち改行が埋め込まれた入力をシェルコマンドにpipeする際には特に顕著な違いが表れる。したがってこのテクニックを用いるLispプログラムは、シェルの要請に応じてリージョンのテキストを個別にフォーマットする必要がある。

Function: shell-command-to-string command

この関数はcommand (文字列)をシェルコマンドとして実行して、そのコマンドの出力を文字列としてリターンする。commandに実際には複数のコマンドが含まれている場合の振る舞いは、呼び出されるシェル(ローカルコマンドについてはshell-file-nameによって決定される)に依存する。特にMS-Windowsではコマンド間の区切りに改行を使えないので、かわりに‘&&’を使う必要がある。

Function: process-lines program &rest args

この関数はprogramを実行して完了を待機して、出力を文字列のリストとしてリターンする。リスト内の各文字列はプログラムのテキスト出力の1つの行を保持する。各行のEOL文字(行末文字)は取り除かれる。programの後の引数argsはそのプログラム実行に際して、コマンドライン引数を指定する文字列。

programが非0のexitステータスでexitすると、この関数はエラーをシグナルする。

この関数はcall-processを呼び出すことにより機能して、プログラムの出力はcall-processの場合と同じ方法でデコードされる。

Function: process-lines-ignore-status program &rest args

この関数はprocess-linesと同様だが、programが非0のexitステータスでexitした場合にエラーをシグナルしない。


Footnotes

(29)

他のシステムではEmacsはlsのLispエミュレーションを使用します。ディレクトリーのコンテンツを参照してください。


This page has generated for branch:work/emacs-30_69b16e5c63840479270d32f58daea923fe725b90, commit:5e3f74b56ff47b5bcef2526c70f53f749bbd45f6 to check Japanese translation.