##
6.1.5 プロセス管理

プロセスを生成したり管理するために、以下の関数を利用することができます。

様々な `exec*()` 関数が、プロセス内にロードされた新たな プログラムに与えるための引数からなるリストをとります。どの場合でも、 新たなプログラムに渡されるリストの最初の引数は、ユーザがコマンドライン で入力する引数ではなく、プログラム自身の名前になります。 C プログラマにとっては、これはプログラムの `main()` に 渡される `argv[0]` になります。例えば、 "`os.execv('/bin/echo', ['foo', 'bar'])`" は、標準出力に "`bar`" を出力します; "`foo`" は無視されたかのように見える ことでしょう。

`abort`( | )

  `SIGABRT` シグナルを現在のプロセスに対して生成します。 Unixでは、標準設定の動作はコアダンプの生成です; Windows では、 プロセスは即座に終了コード `3` を返します。 `signal.signal()` を使って `SIGABRT` に対する シグナルハンドラを設定しているプログラムは異なる挙動を示すので 注意してください。

  利用できる環境: Unix、Windows。

`execl`( | path, arg0, arg1, ...)

`execle`( | path, arg0, arg1, ..., env)

`execlp`( | file, arg0, arg1, ...)

`execlpe`( | file, arg0, arg1, ..., env)

`execv`( | path, args)

`execve`( | path, args, env)

`execvp`( | file, args)

`execvpe`( | file, args, env)

  これらの関数はすべて、現在のプロセスを置き換える形で新たな プログラムを実行します; 現在のプロセスは戻り値を返しません。 Unixでは、新たに実行される実行コードは現在のプロセス内に ロードされ、呼び出し側と同じプロセス ID を持つことになります。 エラーは `OSError` 例外として報告されます。

  "`l`" および "`v`" のついた `exec*()` 関数は、コマンドライン引数をどのように渡すかが異なります。 "`l`" 型は、コードを書くときにパラメタ数が決まっている場合 に、おそらくもっとも簡単に利用できます。個々のパラメタは単に `execl*()` 関数の追加パラメタとなります。"`v`" 型は、 パラメタの数が可変の時に便利で、リストかタプルの引数が args パラメタとして渡されます。どちらの場合も、子プロセスに渡す引数は 動作させようとしているコマンドの名前から始まらなくてはなりません。

  末尾近くに "`p`" をもつ型 (`execlp()`、 `execlpe()`、 `execvp()`、 および `execvpe()`) は、プログラム file を探すために 環境変数 PATH を利用します。環境変数が (次の段で述べる `exec*e()` 型関数で) 置き換えられる場合、環境変数は PATH を決定する上の情報源として使われます。 その他の型、`execl()`、 `execle()`、 `execv()`、 および `execve()` では、実行 コードを探すために PATH を使いません。 path には適切に設定された絶対パスまたは相対パスが 入っていなくてはなりません。

  `execle()`、 `execlpe()`、 `execve()`、 および `execvpe()` (全て末尾に"`e`" がついていること に注意してください) では、env パラメタは新たなプロセスで利用 される環境変数を定義するためのマップ型でなくてはなりません; `execl()`、`execlp()`、 `execv()`、 および `execvp()` では、全て新たなプロセスは現在のプロセス の環境を引き継ぎます。利用できる環境: Unix、Windows。

`_exit`( | n)

  終了ステータス n でシステムを終了します。このとき クリーンアップハンドラの呼び出しや、標準入出力バッファの フラッシュなどは行いません。利用できる環境: Unix、Windows。

  注意: システムを終了する標準的な方法は `sys.exit(n)` です。`_exit()` は通常、 `fork()` された後の子プロセス でのみ使われます。

以下の終了コードは必須ではありませんが `_exit()` と共に使うこと ができます。一般に、 メールサーバの外部コマンド配送プログラムのような、 Python で書かれたシステムプログラムに使います。

`EX_OK`
  エラーが起きなかったことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_USAGE`
  誤った個数の引数が渡されたときなど、コマンドが間違って使われたことを表す 終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_DATAERR`
  入力データが間違っていたことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_NOINPUT`
  入力ファイルが存在しなかった、または、読み込み不可だったことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_NOUSER`
  指定されたユーザが存在しなかったことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_NOHOST`
  指定されたホストが存在しなかったことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_UNAVAILABLE`
  要求されたサービスが利用できないことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_SOFTWARE`
  内部ソフトウェアエラーが検出されたことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_OSERR`
  fork できない、pipe の作成ができないなど、オペレーティング・システム・エ ラーが検出されたことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_OSFILE`
  システムファイルが存在しなかった、開けなかった、あるいはその他のエラーが 起きたことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_CANTCREAT`
  ユーザには作成できない出力ファイルを指定したことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_IOERR`
  ファイルの I/O を行っている途中にエラーが発生したときの終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_TEMPFAIL`
  一時的な失敗が発生したことを表す終了コード。これは、再試行可能な操作の途 中に、ネットワークに接続できないというような、実際にはエラーではないかも 知れないことを意味します。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_PROTOCOL`
  プロトコル交換が不正、不適切、または理解不能なことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_NOPERM`
  操作を行うために十分な許可がなかった（ファイルシステムの問題を除く）こと を表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_CONFIG`
  設定エラーが起こったことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`EX_NOTFOUND`
  ``an entry was not found'' のようなことを表す終了コード。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`fork`( | )

  子プロセスを fork します。子プロセスでは `0` が返り、 親プロセスでは子プロセスの id が返ります。 利用できる環境: Unix。

`forkpty`( | )

  子プロセスを fork します。このとき新しい擬似端末 (psheudo-terminal) を子プロセスの制御端末として使います。 親プロセスでは `(pid, fd)` からなるペアが返り、fd は擬似端末の マスタ側 (master end) のファイル記述子となります。可搬性のある アプローチを取るためには、`pty` モジュールを利用してください。 利用できる環境: いくつかの Unix系。

`kill`( | pid, sig)

  プロセス pid をシグナル sig で kill します。 ホストプラットフォームで利用可能なシグナルを特定する定数は `signal` モジュールで定義されています。 利用できる環境: Unix。

`killpg`( | pgid, sig)

  プロセスグループ pgid をシグナル sig 付きで kill する。 利用できる環境: Unix。 バージョン2.3 以降で新規追加された 仕様です。

`nice`( | increment)

  プロセスの ``nice 値'' に increment を加えます。新たな nice 値を返します。利用できる環境: Unix。

`plock`( | op)

  プログラムのセグメント (program segment) をメモリ内でロックします。 op (`<sys/lock.h>` で定義されています) にはどのセグメントを ロックするかを指定します。利用できる環境: Unix。

`popen`( | ...)

`popen2`( | ...)

`popen3`( | ...)

`popen4`( | ...)

  子プロセスを起動し、子プロセスとの通信のために開かれたパイプを返します。 これらの関数は 6.1.2 節で記述されています。

`spawnl`( | mode, path, ...)

`spawnle`( | mode, path, ..., env)

`spawnlp`( | mode, file, ...)

`spawnlpe`( | mode, file, ..., env)

`spawnv`( | mode, path, args)

`spawnve`( | mode, path, args, env)

`spawnvp`( | mode, file, args)

`spawnvpe`( | mode, file, args, env)

  新たなプロセス内でプログラム path を実行します。 mode が `P_NOWAIT` の場合、この関数は 新たなプロセスのプロセス ID となります。; mode が `P_WAIT` の場合、子プロセスが正常に終了するとその終了コードが返ります。そうでない 場合にはプロセスを kill したシグナル signal に対して `-signal` が返ります。Windows では、プロセス ID は 実際にはプロセスハンドル値になります。

  "`l`" および "`v`" のついた `spawn*()` 関数は、コマンドライン引数をどのように渡すかが異なります。 "`l`" 型は、コードを書くときにパラメタ数が決まっている場合 に、おそらくもっとも簡単に利用できます。個々のパラメタは単に `spawnl*()` 関数の追加パラメタとなります。"`v`" 型は、 パラメタの数が可変の時に便利で、リストかタプルの引数が args パラメタとして渡されます。どちらの場合も、子プロセスに渡す引数は 動作させようとしているコマンドの名前から始まらなくてはなりません。

  末尾近くに "`p`" をもつ型 (`spawnlp()`、 `spawnlpe()`、 `spawnvp()`、 および `spawnvpe()`) は、プログラム file を探すために 環境変数 PATH を利用します。環境変数が (次の段で述べる `spawn*e()` 型関数で) 置き換えられる場合、環境変数は PATH を決定する上の情報源として使われます。 その他の型、`spawnl()`、 `spawnle()`、 `spawnv()`、 および `spawnve()` では、実行 コードを探すために PATH を使いません。 path には適切に設定された絶対パスまたは相対パスが 入っていなくてはなりません。

  `spawnle()`、 `spawnlpe()`、 `spawnve()`、 および `spawnvpe()` (全て末尾に"`e`" がついていること に注意してください) では、env パラメタは新たなプロセスで利用 される環境変数を定義するためのマップ型でなくてはなりません; `spawnl()`、`spawnlp()`、 `spawnv()`、 および `spawnvp()` では、全て新たなプロセスは現在のプロセス の環境を引き継ぎます。

  例えば、以下の `spawnlp()` および `spawnvpe()` 呼び出し:

      import os
      os.spawnlp(os.P_WAIT, 'cp', 'cp', 'index.html', '/dev/null')

      L = ['cp', 'index.html', '/dev/null']
      os.spawnvpe(os.P_WAIT, 'cp', L, os.environ)

  は等価です。利用できる環境: Unix、Windows。

  `spawnlp()`、`spawnlpe()`、 `spawnvp()` および `spawnvpe()` は Windows では利用できません。 バージョン1.6 以降で新規追加された 仕様です。

`P_NOWAIT`
`P_NOWAITO`
  `spawn*()` 関数ファミリに対する mode パラメタ として取れる値です。この値のいずれかを mode として与えた場合、 `spawn*()` 関数は新たなプロセスが生成されるとすぐに、 プロセスの ID を戻り値として返ります。 利用できる環境: Unix、Windows。 バージョン1.6 以降で新規追加された 仕様です。

`P_WAIT`
  `spawn*()` 関数ファミリに対する mode パラメタ として取れる値です。この値を mode として与えた場合、 `spawn*()` 関数は新たなプロセスを起動して完了するまで返らず、 プロセスがうまく終了した場合には終了コードを、シグナルによってプロセス が kill された場合には `-signal` を返します。 利用できる環境: Unix、Windows。 バージョン1.6 以降で新規追加された 仕様です。

`P_DETACH`
`P_OVERLAY`
  `spawn*()` 関数ファミリに対する mode パラメタ として取れる値です。これらの値は上の値よりもやや可搬性において劣って います。`P_DETACH` は `P_NOWAIT` に似ていますが、 新たなプロセスは呼び出しプロセスのコンソールから切り離され (detach) ます。`P_OVERLAY` が使われた場合、現在のプロセスは 置き換えられます; 従って`spawn*()` は返りません。 利用できる環境: Windows。 バージョン1.6 以降で新規追加された 仕様です。

`startfile`( | path)

  ファイルを関連付けられたアプリケーションを使って「スタート」します。 この動作は、 Windows の Explorer 上でのファイルをダブルクリックや、 コマンドプロンプト (interactive command shell) 上での ファイル名を start 命令の引数としての実行と同様です: ファイルは拡張子が関連付けされているアプリケーション (が存在する場合) を使って開かれます。

  `startfile()` は関連付けされたアプリケーションが起動すると 同時に返ります。アプリケーションが閉じるまで待機させるためのオプション はなく、アプリケーションの終了状態を取得する方法もありません。 path 引数は現在のディレクトリからの相対で表します。 絶対パスを利用したいなら、最初の文字はスラッシュ ("`/`") ではないので注意してください; もし最初の文字がスラッシュ なら、システムの背後にある Win32 `ShellExecute()` 関数は 動作しません。`os.path.normpath()` 関数を使って、Win32 用に 正しくコード化されたパスになるようにしてください。 利用できる環境:Windows。 バージョン2.0 以降で新規追加された 仕様です。

`system`( | command)

  サブシェル内でコマンド (文字列) を実行します。この関数は 標準 C 関数 `system()` を使って実装されており、 `system()` と同じ制限があります。 `posix.environ`、 `sys.stdin` 等に対する変更を行っても、 実行されるコマンドの環境には反映されません。

  Unixでは、戻り値はプロセスの終了ステータスで、`wait()` で定義されている書式にコード化されています。 POSIX は `system()` 関数の戻り値の意味について定義して いないので、Python の `system` における戻り値はシステム依存と なることに注意してください。

  Windows では、戻り値は command を実行した後にシステムシェルから 返される値で、Windows の環境変数 COMSPEC となります: command.com ベースのシステム (Windows 95, 98 および ME) では、この値は常に `0` です; cmd.exe ベースのシステム (Windows NT, 2000 および XP) では、この値は実行したコマンドの終了 ステータスです; ネイティブでないシェルを使っているシステムについては、 使っているシェルのドキュメントを参照してください。

  利用できる環境: Unix、Windows。

`times`( | )

  (プロセスまたはその他の) 積算時間を秒で表す浮動小数点数からなる、 5 要素のタプルを返します。タプルの要素は、ユーザ時間 (user time)、 システム時間 (system time)、子プロセスのユーザ時間、子プロセスの システム時間、そして過去のある固定時点からの経過時間で、この順に 並んでいます。Unix マニュアルページ times(2) または 対応する Windows プラットフォーム API ドキュメントを参照してください。 利用できる環境: Unix、Windows。

`wait`( | )

  子プロセスの実行完了を待機し、子プロセスの pid と終了コードインジケータ -- 16 ビットの数で、下位バイトがプロセスを kill したシグナル番号、上位バイト が終了ステータス (シグナル番号がゼロの場合) -- の入ったタプルを 返します; コアダンプファイルが生成された場合、下位バイトの最上桁ビットが 立てられます。 利用できる環境: Unix。

`waitpid`( | pid, options)

  プロセス id pid で与えられた子プロセスの完了を待機し、 子プロセスのプロセス id と(`wait()` と同様にコード化された) 終了ステータスインジケータからなるタプルを返します。 この関数の動作は options によって影響されます。通常の操作では `0` にします。利用できる環境: Unix。

  pid が `0` よりも大きい場合、 `waitpid()` は特定のプロセスのステータス情報を要求します。pid が `0` の場合、現在のプロセスグループ内の任意の子プロセスの状態 に対する要求です。pid が `-1` の場合、現在のプロセス の任意の子プロセスに対する要求です。pid が `-1` よりも 小さい場合、プロセスグループ `-pid` (すなわち pid の 絶対値) 内の任意のプロセスに対する要求です。

`WNOHANG`
  子プロセス状態がすぐに取得できなかった場合にハングアップしてしまわ ないようにするための `waitpid()` のオプションです。利用できる環境: Unix。

以下の関数は`system()`、 `wait()`、 あるいは`waitpid()` が返すプロセス状態コード を引数にとります。これらの関数はプロセスの配置を決めるために 利用することができます。

`WIFSTOPPED`( | status)

  プロセスが停止された (stop) 場合に真を返します。 利用できる環境: Unix。

`WIFSIGNALED`( | status)

  プロセスがシグナルによって終了した (exit) 場合に真を返します。 利用できる環境: Unix。

`WIFEXITED`( | status)

  プロセスが exit(2) システムコールで終了した場合に 真を返します。利用できる環境: Unix。

`WEXITSTATUS`( | status)

  `WIFEXITED(status)` が真の場合、exit(2) システム コールに渡された整数パラメタを返します。そうでない場合、 返される値には意味がありません。 利用できる環境: Unix。

`WSTOPSIG`( | status)

  プロセスを停止させたシグナル番号を返します。 利用できる環境: Unix。

`WTERMSIG`( | status)

  プロセスを終了させたシグナル番号を返します。利用できる環境: Unix