Tcl 8.4.1　Manual Command Reference

exec

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

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

-keepnewline

- -

<<value

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

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

|: パイプラインにある、個々のコマンドを区切ります。前のコマンドの標準出力が次のコマンドの標準入力とされ、パイプでつながれます。
|&: パイプラインにある個々のコマンドを区切ります。前のコマンドの標準出力と標準エラー出力の両方が次のコマンドの標準入力とされ、パイプでつながれます。このフォーマットのリダイレクションは "2>" や ">&" のフォーマットより優先されます。
< fileName: fileName で指定されるファイルがオープンされ、パイプラインの最初のコマンドの標準入力として使われます。
<@ fileId: FileId はopenコマンドの返り値など、オープンされたファイルの識別子でなければなりません。これがパイプラインにある最初のコマンドの標準入力として使われます。FileIdは読み込みモードでオープンされていなければなりません。
<<value: value が最初のコマンドの標準入力として渡されます。
> fileName: 最後のコマンドの標準出力が fileName で指定されたファイルにリダイレクトされます。ファイルの内容は上書きされます。
2> fileName: パイプラインにある全てのコマンドからの標準エラー出力は、fileNameと指定されたファイルにリダイレクトされます。これまでの関連引数の内容を全て無効にします。
> & fileName: 最後のコマンドからの標準出力と、全てのコマンドからの標準エラー出力の両方は、fileNameと指定されたファイルにリダイレクトされます。これまでの関連引数の内容を全て無効にします。
>> fileName: 最後のコマンドの標準出力が fileName で指定されたファイルにリダイレクトされます。追加書き込みになりますので、ファイルの内容は上書きされることはありません。
2>> fileName: パイプラインにある全てのコマンドの標準エラー出力が fileName というファイルにリダイレクトされます。追加書き込みになりますので、ファイルの内容は上書きされることはありません。
>>& fileName: 最後のコマンドからの標準出力と全てのコマンドからの標準エラー出力の両方はｆileName というファイルにリダイレクトされます。追加書き込みになり、ファイルの内容は上書きされることはありません。
>@ fileId: FileIdは open コマンドの返り値など、オープンされたファイルの識別子でなければなりません。最後のコマンドの標準出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。
2>@ fileId: FileId は openコマンドの返り値など、オープンされたファイルの識別子でなければなりません。すべてのコマンドの標準エラー出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。
>&@ fileId: FileId は openコマンドの返り値など、オープンされたファイルの識別子でなければなりません。最後のコマンドの標準出力とすべてのコマンドの標準エラー出力が fileId のファイルにリダイレクトされます。 fileId は書き込みモードでオープンされていなければなりません。

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

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

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

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

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

移植性問題

Windows ( 全てのバージョン )

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

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

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

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

パスにおける２つ以上スラッシュやバックスラッシュはネットワークパスを示します。例えば、ルートディレクトリ　c:/　とサブ・ディレクトリ/windows/systemを単なる連結で処理すると、c://windows/system ( ２つスラッシュがつながる)になってしまい、これは　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は１つの例です。この種類のアプリケーションはWindows環境では一般的ではありませんが、存在します。

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

Windows NT

アプリケーションを実行しようと試みているとき、最初にexecは指定された名前を検索します。指定された名前がなければ .com、.exe、.batを順番で、指定された名前の末尾に付加したより長い名前を検索します。ディレクトリ名がアプリケーション名の一部として指定されなかった場合、アプリケーションを探すため、次のディレクトリを自動的に順番に検索します。

Tclの実行可能なフィイルがロードされたディレクトリ。
カレント・ディレクトリ。
Windows NT 32ビットシステムディレクトリ。
Windows NT 16ビットシステムディレクトリ。
Windows NT ホームディレクトリ。
パスにリストされたディレクトリ。

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

Windows 95

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

Tcl　の実行可能なフィイルがロードされたディレクトリ。
カレント・ディレクトリ。
Windows 95 システムディレクトリ。
Windows 95 ホームディレクトリ。
パスにリストされたディレクトリ。

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

いったん、１つの16ビットDOSアプリケーションがコンソールから標準入力を読み取ることで中止された場合、後続で実行される全ての16ビットDOSアプリケーションは閉じられた標準入力に遭遇します。たとえ、１つの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