Next: Asynchronous Processes, Previous: Shell Arguments, Up: Processes [Contents][Index]
同期プロセス(synchronous process)の作成後、Emacsは継続する前にそのプロセスの終了を待機します。GNUやUnix19でのDiredの起動が例です。プロセスは同期的なので、Emacsがそれにたいして何か行おうと試みる前にディレクトリーのリスト全体がバッファーに到着します。
同期サブプロセス終了をEmacsが待機する間に、ユーザーはC-gをタイプすることでquitが可能です。最初のC-gはSIGINTシグナルによりサブプロセスのkillを試みます。しかしこれはquitする前に実際にそのサブプロセスが終了されるまで待機します。その間にユーザーがさらにC-gをタイプするとそれはSIGKILLで即座にサブプロセスをkillしてquitします(別プロセスにたいするkillが機能しないMS-DOSを除く)。Quittingを参照してください。
同期サブプロセス関数はプロセスがどのように終了したかの識別をリターンします。
同期サブプロセスからの出力はファイルからのテキスト読み込みと同じように、一般的にはコーディングシステムを使用してデコードされます。call-process-regionによりサブプロセスに送信された入力は、ファイルへのテキスト書き込みと同じようにコーディングシステムを使用してエンコードされます。Coding Systemsを参照してください。
この関数はprogramを呼び出して完了するまで待機する。
サブプロセスのカレント作業ディレクトリー(CWD: current working
directory)はカレントバッファーのdefault-directoryがローカル(unhandled-file-name-directoryにより判断される)ならその値、それ以外は"~"。リモートディレクトリーでプロセスを実行したければprocess-fileを使用すること。
新たなプロセスの標準入力はinfileが非nilならファイルinfile、それ以外ならnullデバイス。引数destinationはプロセスの出力をどこに送るかを指定する。以下は可能な値:
そのバッファーのポイントの前に出力を挿入する。これにはプロセスの標準出力ストリームと標準エラーストリームの両方が含まれる。
その名前のバッファーのポイントの前に出力を挿入する。
tカレントバッファーのポイントの前に出力を挿入する。
nil出力を破棄する。
出力を破棄してサブプロセス完了を待機せずに即座にnilをリターンする。
この場合にはプロセスはEmacsと並列に実行可能なので真に同期的ではない。しかしこの関数リターン後は本質的にはすみやかにEmacsがサブプロセスを終了するという点から、これを同期的と考えることができる。
MS-DOSは非同期サブプロセスをサポートせずこのオプションは機能しない。
(:file file-name)指定されたファイルに出力を送信して、ファイルが既に存在すれば上書きする。
(real-destination error-destination)標準出力ストリームを標準エラーストリームと分けて保持する。通常の出力はreal-destinationの指定にしたがって扱い、エラー出力はerror-destinationにしたがって処分する。error-destinationがnilならエラー出力の破棄、tなら通常の出力と混合することを意味して、文字列ならそれはエラー出力をリダイレクトするファイルの名前である。
エラー出力先に直接バッファーを指定することはできない。ただしエラー出力を一時ファイルに送信して、サブプロセス終了時にそのファイルをバッファーに挿入すればこれを達成できる。
displayが非nilなら、call-processは出力の挿入にしたがってバッファーを再表示する(しかし出力のデコードに選択されたコーディングシステムが実データからエンコーディングを推論することを意味するundecidedなら、非ASCIIに一度遭遇すると再表示が継続不能になることがある。これを修正するのが困難な根本的理由が存在する。Output from Processesを参照)。
それ以外なら関数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))
この関数は別プロセス内でファイルを同期的に処理する。これはcall-processと似ているが、サブプロセスのカレントワーキングディレクトリーを指定する変数default-directoryの値にもとづいて、ファイルハンドラーを呼び出すかもしれない。
引数はcall-processの場合とほとんど同様の方法で処理されるが以下の違いがある:
引数infile、buffer、displayのすべての組み合わせと形式をサポートしないファイルハンドラーがあるかもしれない。たとえば実際に渡された値とは無関係に、displayがnilであるかのように振る舞うファイルハンドラーがいくつかある。他の例としては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 File Namesを参照)。
この変数はprocess-file呼び出しがリモートファイルを変更するかどうかを示す。
この変数はデフォルトではprocess-file呼び出しがリモートホスト上の任意のファイルを潜在的に変更し得ることを意味するtに常にセットされる。nilにセットされた際には、リモートファイル属性のキャッシュにしたがうことによりファイルハンドラーの挙動を最適化できる可能性がある。
この変数は決してsetqではなく、常にletバインディングでのみ変更すること。
この関数はstartからendのテキストを、実行中のプロセスprogramに標準入力として送信する。これはdeleteが非nilなら送信したテキストを削除する。これは出力をカレントバッファーの入力箇所に挿入するために、destinationをtに指定している際に有用。
引数destinationとdisplayはサブロセスからの出力にたいして何を行うか、および出力の到着にともない表示を更新するかどうかを制御する。詳細は上述の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は自身の標準入力を標準出力へコピーする。引数destinationがtなので出力はカレントバッファーに挿入される。
---------- 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に出力
この関数はshellコマンドcommandを非同期に実行する。他の引数はcall-processの場合と同様に処理される。古い呼び出し規約はdisplayの後に任意個数の追加引数を許容して、これはcommandに結合される。これはまだサポートされるものの使用しないことを強く推奨する。
この関数はcall-process-shell-commandと同様だが内部的にprocess-fileを使用する点が異なる。default-directoryに依存してcommandはリモートホスト上でも実行可能。古い呼び出し規約はdisplayの後に任意個数の追加引数を許容して、これはcommandに結合される。これはまだサポートされるものの使用しないことを強く推奨する。
この関数はstartとendの間のテキストを、commandを実行するシェルの標準入力として送信する。これはプロセスがシェルであるようなcall-process-regionと類似している。引数delete、destination、およびリターン値はcall-process-regionと同様。この関数は追加の引数を受け付けないことに注意。
この関数はshellコマンドとしてcommand (文字列)を実行してコマンドの出力を文字列としてリターンする。
この関数はprogramを実行して完了を待機して、出力を文字列のリストとしてリターンする。リスト内の各文字列はプログラムのテキスト出力の1つの行を保持する。各行のEOL文字(行末文字)は取り除かれる。programの後の引数argsはそのプログラム実行に際して、コマンドライン引数を指定する文字列。
programが非0のexitステータスでexitすると、この関数はエラーをシグナルする。
この関数はcall-processを呼び出すことにより機能して、プログラムの出力はcall-processの場合と同じ方法でデコードされる。
Next: Asynchronous Processes, Previous: Shell Arguments, Up: Processes [Contents][Index]