exec

ReferenceTOPKeywords

コマンド名

exec - サブプロセスを起動します。

構文

exec ?switches? arg ?arg ...?

解説

本コマンドの引数は1つ以上のサブプロセスを指定するものです。これらの引数は標準的なシェル・パイプラインのフォーマットに準じます。それぞれのarg がコマンドを構成する文字列になり、それぞれのコマンドがサブプロセスになります。

exec の第1の引数が「 - 」で始まっている場合、この引数は exec コマンドに対するパイプラインの指定ではなく、コマンド・ライン・スイッチだとみなされます。現在サポートされているオプションは下記のものです。

-keepnewline
- -
|
|&
< fileName
< @ fileId
<<value
> fileName
2> fileName
>& fileName
>> fileName
2>> fileName
>>& fileName
>@ fileId
2>@ fileId
>&@ fileId
-keepnewline
 
パイプラインの出力における最後の改行コードを保持します。通常、最後の改行コードは削除されます。
- -
 
スイッチの終わりを示します。直後の引数が「 - 」で始まっていても、第1の引数arg であるとみなされます。

arg (または arg のペア) は次の何れかのフォーマットであれば、 exec はこれらの引数を使って、サブプロセスの間の入力・出力フローを制御します。 これらの引数はサブプロセスには渡されません。 '"< fileName'"のようなフォーマットの場合は、 "<'"とfileName は別々の引数として書いても構いませんし、間にスペースを入れずに1つの引数にしても (例えば、"<fileName")構いません。

|
パイプラインにある、個々のコマンドを区切ります。 前のコマンドの標準出力が次のコマンドの標準入力とされ、パイプでつながれます。

|&
パイプラインにある個々のコマンドを区切ります。 前のコマンドの標準出力と標準エラー出力の両方が次のコマンドの標準入力とされ、パイプでつながれます。このフォーマットのリダイレクションは "2>" や ">&" のフォーマットより優先されます。

< fileName
fileName で指定されるファイルがオープンされ、 パイプラインの最初のコマンドの標準入力として使われます。

<@ fileId
FileIdopenコマンドの返り値など、オープンされたファイルの識別 子でなければなりません。これがパイプラインにある最初のコマンドの標準入力として使われます。FileIdは読み込みモードでオープンされていなければなりません。

<<value 
value が最初のコマンドの標準入力として渡されます。

> fileName
最後のコマンドの標準出力が fileName で指定されたファイルにリダイレクトされます。ファイルの内容は上書きされます。

2> fileName
パイプラインにある全てのコマンドからの標準エラー出力は、fileNameと指定されたファイルにリダイレクトされます。これまでの関連引数の内容を全て無効にします。

> & fileName
最後のコマンドからの標準出力と、全てのコマンドからの標準エラー出力の両方は、fileNameと指定されたファイルにリダイレクトされます。これまでの関連引数の内容を全て無効にします。

>> fileName
最後のコマンドの標準出力が fileName で指定されたファイルにリダイレクトされます。追加書き込みになりますので、ファイルの内容は上書きされることはありません。

2>> fileName
パイプラインにある全てのコマンドの標準エラー出力が fileName というファイルにリダイレクトされます。追加書き込みになりますので、ファイルの内容は上書きされることはありません。

>>& fileName
最後のコマンドからの標準出力と全てのコマンドからの標準エラー出力の両方はfileName というファイルにリダイレクトされます。追加書き込みになり、ファイルの内容は上書きされることはありません。

>@ fileId
FileIdopen コマンドの返り値など、オープンされたファイルの識別 子でなければなりません。最後のコマンドの標準出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。

2>@ fileId
FileIdopenコマンドの返り値など、オープンされたファイルの識別 子でなければなりません。すべてのコマンドの標準エラー出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。

>&@ fileId
FileIdopenコマンドの返り値など、オープンされたファイルの識別 子でなければなりません。最後のコマンドの標準出力とすべてのコマンドの標準エラー出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。

標準出力がリダイレクトされなかった場合には execコマンドはパイプライ ンにある最後のコマンドの標準出力の内容を返します。もしパイプラインのコマンドのどれかが異常終了したり、 中止されたり、サスペンドさせられたりした場合には、 execはエラーを返し、エラーメッセージにはパイプラインの出力と、異常終了を知らせるメッセージが含まれます。また、errorCode変数には最後の異常終了に 関する追加の情報が含まれます。もしコマンドのどれかが標準エラー出力に書き出し、標準エラー出力がリダイレクトされていなかった場合には 、execはエラーを返し、エラーメッセージにはパイプラインの出力に続いて、異常終了についてのメッセージ、さらに標準エラーが出力されます。

結果やエラーメッセージの最後の文字が改行コードである場合には、その改行コードは削除されます。これは他のTcl の返り値が改行で終了しないので、それと一致させるためです。ただし-keepnewline オプションが指定されている場合、最後の改行コードは保持されます。

標準入力が"<" や "<<" や "<@" でリダイレクトされなかった場合には、パイプラインの最初のコマンドの標準入力はアプリ ケーションの現在の標準入力になります。

最後の引数argが "&" である場合には、そのパイプラインはバックグラウンドで実行されます。この場合、execコマンドはパイプラインの全サブプロセスのプロセス識別 子からなるリストを返します。パイプラインの最後のコマンドの標準出力は、リダイレクトされていない場合、アプリケーションの標準出力で出力されます。パイプラインの全てのコマンドのエラー出力はリダイレクトされていない場合、アプリケーションの標準エラー出力で出力されます。 

各コマンドにおける最初の文字列はコマンド名とみなされます。"~" の拡張が行なわれ、その結果 スラッシュが入っていなければ環境変数PATHを使って実行ファイルが探します。スラッシュが入っている場合、カレントディレクトリから到達可能な実行可能なファイルを指していなければなりません。コマンドの引数に対し て"glob" 展開やその他のシェル置換は行われません。

移植性問題

Windows ( 全てのバージョン )
@ fileId” 表記法によるソケットの読み書きは機能しません。ソケットからの読み込みには、16ビットDOSアプリケーションはハングアップしますが、32ビットアプリケーションは end-of-file で直ちに戻ります。ソケットへの書き込みには、2種類のアプリケーションいずれもその情報をソケットの代りに、コンソールが存在すれば、コンソールへ送ります。存在しなければ、廃棄されます。

TkコンソールのTextウィジェットは本当の標準I/O機能を提供しません。Tkで標準入力からリダイレクトされるとき、全てのアプリケーションは即座に end-of-file をもらいます。標準出力や標準エラー出力へリダイレクトされる情報は放棄されます。

Tclコマンドへの引数ではスラッシュ、バックスラッシュのいずれもがパスの区切りとして認められます。アプリケーションを実行するとき、アプリケーションのために指定されたパス名には、パス区切りとしてスラッシュやバックスラッシュを含むことがあります。しかし、ほとんどの Windows アプリケーションは、オプションの区切りとしてスラッシュのみを認め、パスの区切りとしてバックスラッシュのみを認めることに注意が必要です。アプリケーションへの引数として、パス名をスラッシュで指定したものは、自動的にバックスラッシュ文字を使うものに変換されることはありません。スラッシュを区切りとする引数が、パス名として認められるかどうかはプログラムによって異なります。

また、16ビットDOS や Windows 3.Xをアプリケーションをコールするとき、全てのパス名は短い簡潔なパスフォーマット ( 例えば、「applbakery.default」の代わりに「applba~1.def」) を使わなければなりません。これは file attributes $fileName -shortname コマンドで取得できます。

パスにおける2つ以上スラッシュやバックスラッシュはネットワークパスを示します。例えばルートディレクトリ c:/ とサブ・ディレクトリ/windows/systemを単なる連結で処理すると、c://windows/system ( 2つスラッシュがつながる)になってしまい、これは windows (c:/ は無視される )というマシン上systemというマウントポイントを示します。(本来表現したい)現在のコンピュータでのディレクトリ  c:/windows/system にはなりません。 file join コマンドはパスのコンポーネントを(正しく)連結するために使われます。
2つ種類のWin32コンソールアプリケーションがあることに注意しましょう。
1 ) CLI -- CommandLine Interface 、簡単な標準I/O(stdio)コマンドです。 例えば、netstat.exe
2 ) TUI -- Textmode User Interface、カーソルの移動、テキストカラーの設定、キーの押下、マウスの移動などコンソールAPIにアクセスするあらゆるアプリケーションです。Windows 2000からのtelnet.exeは1つの例です。この種類のアプリケーションはWindows環境では一般 的ではありませんが、存在します。

コンソールが存在しないとき、execTUIアプリケーションではうまく動作しません。 コンソールアプリケーションを隠すか、隔離状態にすることが望ましいです。 これはexecがパイプ上で通信することを望むための設計上の制限です。どうしてもTUIアプリケーションの間の通 信をしたい場合、Expect拡張が参考になります。

Windows NT
 
アプリケーションを実行しようと試みているとき、最初にexecは指定された名前を検索します。指定された名前がなければ .com.exe.batを順番で、指定された名前の末尾に付加したより長い名前を検索します。ディレクトリ名がアプリケーション名の一部として指定されなかった場合、アプリケーションを探すため、次のディレクトリを自動的に順番に検索します。
Tclの実行可能なフィイルがロードされたディレクトリ。
カレント・ディレクトリ。
Windows NT 32ビットシステムディレクトリ。
Windows NT 16ビットシステムディレクトリ。
Windows NT ホームディレクトリ。
パスにリストされたディレクトリ。

dircopy のようなシェル固有のコマンドを実行するためには実行したいコマンドの前に「cmd.exe /c」を付けなければなりません。

Windows 95
 
アプリケーションを実行しようと試みているとき、最初にexecは指定された名前を検索します。なければ .com.exe.batを順番で、指定された名前の末尾に付加したより長い名前を検索します。ディレクトリ名前がアプリケーション名の一部として指定されなかった場合、アプリケーションの位 置を探すため、次のディレクトリは自動的に順番に検索します。
Tcl の実行可能なフィイルがロードされたディレクトリ。
カレント・ディレクトリ。
Windows 95 システムディレクトリ。
Windows 95 ホームディレクトリ。
パスにリストされたディレクトリ。

dircopy のようなシェル固有のコマンドを実行するためには実行したいコマンド前に「cmd.exe /c」を付けなければなりません。

いったん、1つの16ビットDOSアプリケーションがコンソールから標準入力を読み取ることで中止された場合、後続で実行される全ての16ビットDOSアプリケーションは閉じられた標準入力に遭遇します。たとえ、1つの16ビットDOSアプリケーションが標準入力が既に閉じていると思い込んでいても、32ビットアプリケーションにはこの問題がなく、正しく実行できます。現時点ではこのバグをつぶすための解決策はまだありません。

NUL:デバイスと16ビットアプリケーションの間のリダイレクションは常に機能するとは限りません。NUL:からリダイレクトされるとき、ハングアップするアプリケーションや、"0x01"列の無限ストリームを受けるアプリケーションや、あるいは直ちにend-of-fileを正しく得るアプリケーションもあります。この振る舞いはアプリケーションにコンパイルされた「何か」に依存すると考えられます。いくつかのアプリケーションは、約4Kを超えるものをNUL:にリダイレクトするとハングアップします。 前述の問題は32ビットアプリケーションではこの問題は起こりません。

全てのDOS 16ビットアプリケーションは同期的に実行されます。パイプから16ビットDOSアプリケーションまでの標準入力の全ては一時ファイルに集められます。そしてパイプの向こう側は16ビットのDOSアプリケーションが実行し始める前に閉じられなければなりません。16ビットDOSアプリケーションからパイプまでの標準出力と標準エラーの全ては一時ファイルに集められます。一時ファイルがパイプラインの次のステージにリダイレクトされる前に、そのアプリケーションは終了しなければなりません。 これはWindows 95の実装パイプのバグ及びWindows 95のOSシェルのパイプの扱い方自身に問題があるためです。

command.comのようなアプリケーションは対話型で実行されるべきではありません。それらの標準入力や標準出力の代わりにコンソールウィンドウに直接アクセスするアプリケーションは失敗することがあり、そしてTclはハングアップする恐れがあり、また、私用のコンソールウィンドウが利用可能ではない場合はシステム自身がハングアップする可能性もあります。

Macintosh
Macintosh では、execコマンドは実装されず、存在しません。
Unix
execコマンドは十分に機能的で、示されたように働きます。

参照

error, open

キーワード

execute, pipeline, redirection, subprocess


Copyright © 1993 The Regents of the University of California. Copyright © 1994-1996 Sun Microsystems, Inc. Copyright © 1995-1997 Roger E. Critchlow Jr.