exec - サブプロセスを呼び出す
シノプシス
エグゼクティブ ？ スイッチ ？ arg ？ arg ... ？
説明
このコマンドは、引数を、実行する1つ以上のサブプロセスの指定として扱います。 引数は、各argがコマンドの1ワードになり、それぞれの異なるコマンドがサブプロセスになる標準のシェルパイプラインの形式をとります。
execの最初の引数が- で始まる場合、それらはコマンドラインスイッチとして扱われ、パイプライン仕様の一部ではありません。 現在サポートされているスイッチは次のとおりです。
-keepnewline
パイプラインの出力に後続の改行を保持します。 通常、末尾の改行は削除されます。
-
スイッチの終了をマークします。 この後の引数は、 -で始まっても最初のargとして扱われます。
arg （またはargのペア）が以下に説明する形式のいずれかを持つ場合、 execによってサブプロセス間の入出力の流れを制御するためにexecによって使用されます。 そのような引数はサブプロセスに渡されません。 `` < fileName ''のような形式では、 fileNameは `` <''とは別の引数か、間に空白がない同じ引数（ `` < fileName ''）のどちらかにあります。
|
パイプライン内の異なるコマンドを区切ります。 前述のコマンドの標準出力は、次のコマンドの標準入力にパイプされます。
|＆
パイプライン内の異なるコマンドを区切ります。 前述のコマンドの標準出力と標準エラーの両方が、次のコマンドの標準入力にパイプされます。 この形式のリダイレクションは、2>や>＆などのフォームをオーバーライドします。
< ファイル名
fileNameで指定されたファイルがオープンされ、パイプラインの最初のコマンドの標準入力として使用されます。
<@ fileId
FileIdは、以前にopenを呼び出したときの戻り値など、開いているファイルの識別子でなければなりません。 これは、パイプラインの最初のコマンドの標準入力として使用されます。 FileIdは読み込み用に開かれている必要があります。
<< value
値は標準入力として最初のコマンドに渡されます。
> fileName
最後のコマンドの標準出力はfileNameという名前のファイルにリダイレクトされ、以前の内容は上書きされます。
2> fileName
パイプラインのすべてのコマンドの標準エラーは、 fileNameという名前のファイルにリダイレクトされ、以前の内容を上書きします。
>＆ fileName
最後のコマンドの標準出力とすべてのコマンドの標準エラーの両方がfileNameという名前のファイルにリダイレクトされ、前の内容が上書きされます。
>> fileName
最後のコマンドの標準出力は、 fileNameという名前のファイルにリダイレクトされ、上書きされるのではなく、追加されます。
2 >> ファイル名
パイプラインのすべてのコマンドの標準エラーは、 fileNameという名前のファイルにリダイレクトされ、上書きされずに追加されます。
>>＆ fileName
最後のコマンドの標準出力とすべてのコマンドの標準エラーは、 fileNameという名前のファイルにリダイレクトされ、上書きされずに追加されます。
> @ fileId
FileIdは、以前にopenを呼び出したときの戻り値など、開いているファイルの識別子でなければなりません。 最後のコマンドの標準出力はfileIdのファイルにリダイレクトされます。このファイルは書き込みのために開かれていなければなりません。
2> @ fileId
FileIdは、以前にopenを呼び出したときの戻り値など、開いているファイルの識別子でなければなりません。 パイプラインのすべてのコマンドの標準エラーはfileIdのファイルにリダイレクトされます。 ファイルは書き込み用に開かれている必要があります。
>＆@ fileId
FileIdは、以前にopenを呼び出したときの戻り値など、開いているファイルの識別子でなければなりません。 最後のコマンドの標準出力とすべてのコマンドの標準エラーの両方がfileIdのファイルにリダイレクトされます。 ファイルは書き込み用に開かれている必要があります。
標準出力がリダイレクトされていない場合、 execコマンドはパイプラインの最後のコマンドの標準出力を返します。 パイプライン内のコマンドのいずれかが異常終了した場合、またはkillまたは中断された場合、 execはエラーを返し、エラーメッセージにはパイプラインの出力が続き、異常終了を示すエラーメッセージが続きます。 errorCode変数には最後に発生した異常終了に関する追加情報が含まれます。 いずれかのコマンドが標準エラーファイルに書き込みを行い、その標準エラーがリダイレクトされない場合、 execはエラーを返します。 エラーメッセージには、パイプラインの標準出力、異常終了に関するメッセージ（存在する場合）、続いて標準エラー出力が続きます。
結果またはエラーメッセージの最後の文字が改行である場合、その文字は通常は結果またはエラーメッセージから削除されます。 これは、通常は改行で終わらない他のTcl戻り値と一致します。 ただし、 -keepnewlineが指定されている場合、末尾の改行は保持されます。
標準入力が `` <」または `` << "または` `@ ''でリダイレクトされない場合、パイプラインの最初のコマンドの標準入力はアプリケーションの現在の標準入力から取得されます。
最後のargが ``＆ ''ならば、パイプラインはバックグラウンドで実行されます。 この場合、 execコマンドは、要素がパイプライン内のすべてのサブプロセスのプロセス識別子であるリストを返します。 パイプラインの最後のコマンドの標準出力は、リダイレクトされていなければアプリケーションの標準出力に送られ、リダイレクトされない限り、パイプラインのすべてのコマンドからのエラー出力はアプリケーションの標準エラーファイルに送られます。
各コマンドの最初の単語がコマンド名として使用されます。 チルダ置換が実行され、結果にスラッシュが含まれていない場合は、PATH環境変数のディレクトリで指定された名前で実行可能ファイルが検索されます。 名前にスラッシュが含まれている場合は、現在のディレクトリから到達可能な実行可能ファイルを参照する必要があります。 `` glob ''拡張や他のシェルのような置換は、コマンドの引数に対して実行されません。
移植性の問題
Windows （すべてのバージョン）
`` @ fileId ''表記を使って、ソケットの読み書きをすることはできません。 ソケットから読み取ると、16ビットDOSアプリケーションがハングアップし、32ビットアプリケーションがファイルの終わりですぐに戻ります。 いずれかのタイプのアプリケーションがソケットに書き込むと、その情報は代わりにコンソールに送信されます（存在する場合）、または破棄されます。
Tkコンソールのテキストウィジェットは、実際の標準IO機能を提供していません。 Tkでは、標準入力からリダイレクトすると、すべてのアプリケーションに直ちにEOFが表示されます。 標準出力または標準エラーにリダイレクトされた情報は破棄されます。
前方スラッシュまたはバックスラッシュのいずれかは、Tclコマンドへの引数のパス区切りとして受け入れられます。 アプリケーションを実行するとき、アプリケーションに指定されたパス名には、パス区切り文字としてフォワードスラッシュまたはバックスラッシュを含めることもできます。 しかし、ほとんどのWindowsアプリケーションでは、スラッシュを引数として受け入れるのはオプションの区切り文字とバックスラッシュのみです。 フォワードスラッシュでパス名を指定するアプリケーションの引数は、バックスラッシュ文字を使用するように自動的には変換されません。 引数にパス区切り文字としてスラッシュが含まれている場合は、プログラムに応じてパス名として認識される場合と認識されない場合があります。
さらに、16ビットのDOSまたはWindows 3.Xアプリケーションを呼び出すときは、すべてのパス名は、短い、隠れた、パス形式を使用する必要があります（たとえば、 `` applbakery.default ''の代わりに `` applba〜1.def '' ）。
パス内の行の2つ以上のフォワードスラッシュまたはバックスラッシュは、ネットワークパスを参照します。 たとえば、ルートディレクトリc：/をサブディレクトリ/ windows / systemと単純に連結すると、 c：// windows / system （2つのスラッシュは一緒になります ）となります。 c：/は無視されます）、現在のコンピュータのディレクトリを記述するc：/ windows / systemと等価ではありません。 file joinコマンドは、パスコンポーネントを連結するために使用する必要があります。
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のようなシェル組み込みコマンドを実行するには、呼び出し側は `` command.com / c ''を目的のコマンドに追加する必要があります。
16ビットDOSアプリケーションがコンソールから標準入力を読み込んで終了すると、後で実行されるすべての16ビットDOSアプリケーションに標準入力が既に閉じられていると表示されます。 32ビットアプリケーションにはこの問題はなく、16ビットDOSアプリケーションが標準入力が閉じられていると判断した後でも、正しく動作します。 現時点でこのバグの回避策はありません。
NUL：デバイスと16ビットアプリケーションの間のリダイレクトが常に機能するとは限りません。 NUL：からリダイレクトすると、アプリケーションによってはハングアップし、他のアプリケーションは `0x01 'バイトの無限ストリームを取得し、実際にはファイルの終わりを正しく取得するものもあります。 その動作は、アプリケーション自体にコンパイルされたものに依存するように見えます。 4K程度以上のNUL：にリダイレクトすると、一部のアプリケーションがハングします。 上記の問題は、32ビットアプリケーションでは発生しません。
すべてのDOS 16ビットアプリケーションは同期して実行されます。 パイプから16ビットDOSアプリケーションへのすべての標準入力は、一時ファイルにまとめられます。 16ビットDOSアプリケーションの実行が開始される前に、パイプのもう一方の端を閉じる必要があります。 16ビットDOSアプリケーションからパイプへのすべての標準出力またはエラーは、一時ファイルに収集されます。 テンポラリファイルがパイプラインの次の段階にリダイレクトされる前に、アプリケーションを終了する必要があります。 これは、パイプの実装におけるWindows 95のバグの回避策によるものであり、標準のWindows 95 DOSシェルがパイプ自体をどのように処理するかです。
command.comなどの特定のアプリケーションは、対話形式で実行しないでください。 標準入力から読み込んで標準出力に書き込むのではなく、コンソールウィンドウに直接アクセスするアプリケーションは、失敗したり、Tclをハングしたり、独自のプライベートコンソールウィンドウが利用できない場合にシステムをハングすることさえあります。
マッキントッシュ
execコマンドは実装されておらず、Macintoshでは存在しません。
Unix
execコマンドは完全に機能し、説明したように動作します。
関連項目
エラー （n）、オープン（n）
キーワード
実行、パイプライン、リダイレクション、サブプロセス
重要： manコマンド（ ％man ）を使用して、特定のコンピュータでコマンドがどのように使用されているかを確認してください。