## Tcl9.0.3/Tk9.0.3 Documentation > Tcl Commands > exec

### Tcl/Tk Applications | Tcl Commands | Tk Commands | [incr Tcl] Package Commands | SQLite3 Package Commands | TDBC Package Commands | tdbc::mysql Package Commands | tdbc::odbc Package Commands | tdbc::postgres Package Commands | tdbc::sqlite3 Package Commands | Thread Package Commands | Tcl C API | Tk C API | [incr Tcl] Package C API | TDBC Package C API

  NAME
    exec — 副処理を起動する 　Invoke subprocesses
  構文 SYNOPSIS
  説明 DESCRIPTION
    -encoding encodingName
    -ignorestderr
    -keepnewline
    --
    |
    |&
    < fileName
    <@ fileId
    << value
    > fileName
    2> fileName
    >& fileName
    >> fileName
    2>> fileName
    >>& fileName
    >@ fileId
    2>@ fileId
    2>@1
    >&@ fileId
  互換性の問題 PORTABILITY ISSUES
    Windows (all versions)
    Unix (including macOS)
  UNIX 実施例 UNIX EXAMPLES
  非零の結果を返す場合 WORKING WITH NON-ZERO RESULTS
  引用記号のある引数を使う　WORKING WITH QUOTED ARGUMENTS
  展開を含む稼働 WORKING WITH GLOBBING
  使用者が提供する対話記述譜断片で WORKING WITH USER-SUPPLIED SHELL SCRIPT FRAGMENTS
  Windows での実施例　WINDOWS EXAMPLES
  タイプ入力画面から使う WORKING WITH CONSOLE PROGRAMS
  組込み命令を使う WORKING WITH COMMAND BUILT-INS
  元々のファイル名を使う WORKING WITH NATIVE FILENAMES
  SEE ALSO
  KEYWORDS

### NAME

exec — 副処理を起動する 　Invoke subprocesses

### 構文 SYNOPSIS

exec ?switches? arg ?arg ...? ?&?

### 説明 DESCRIPTION

この命令は､その引数を､一つ或いはそれ以上の､実行すべき副手続の明細として取扱う｡引数は､標準的な対話機能のパイプの形式をとり､そこでは､各引数 arg は命令の一語をなし､各個別の命令が副手続きになる｡命令の結果はパイプライン内の最終の副手順の標準出力であり､大系の符号化を使って解釈される； 何か他の(殊に二進符号データを含む)符号系を使用する為には､パイプラインは､開かれ､構成設定され､明示的に読まれなければならない｡ 　 　 This command treats its arguments as the specification of one or more subprocesses to execute. The arguments take the form of a standard shell pipeline where each arg becomes one word of a command, and each distinct command becomes a subprocess. The result of the command is the standard output of the final subprocess in the pipeline, interpreted using the system encoding; to use any other encoding (especially including binary data), the pipeline must be opened, configured and read explicitly.

exec の最初の引数が､ - で始まっていると､それらは命令並び・切替子として扱われ､パイプラインの詳述の一部ではない｡現在の処､次の切替子が運用されている: If the initial arguments to exec start with - then they are treated as command-line switches and are not part of the pipeline specification. The following switches are currently supported:

-encoding encodingName
  最初の副処理の出力を復号する為に使う符号化の名前を指定する｡ encoding system 命令の返りが無為設定になる｡ Specifies the name of the encoding to use to decode the output of the first subprocess. Defaults to that returned by the encoding system command.

-ignorestderr
  exec 命令に対して､不都合が生じた場合の､パイプラインの標準不都合通信路への､伝達文の出力の扱いを､止めさせる｡ Stops the exec command from treating the output of messages to the pipeline's standard error channel as an error case.

-keepnewline
  パイプラインの出力の末尾の改行を保持する｡末尾の改行は通常は削除される｡　　　 Retains a trailing newline in the pipeline's output. Normally a trailing newline will be deleted.

--
  切替子の終りを示す｡この後に続く引数は､ -で始っても最初の引数 arg として扱われる｡ 　　　 Marks the end of switches. The argument following this one will be treated as the first arg even if it starts with a -.

arg （または arg の対）が､以下で説明する孰れかの形式を有する場合､それは､exec によって､副手続きの間の入力と出力の流れを制御する為に使用される｡そのような引数は副手続きに渡されることはない｡ “< fileName” の形式中のファイル名 arg は､ “<” から独立した別の引数のこともあり､又は､介在する空白なしの同一引数（即ち､ “<fileName” ）のこともある｡ If an arg (or pair of args) has one of the forms described below then it is used by exec to control the flow of input and output among the subprocess(es). Such arguments will not be passed to the subprocess(es). In forms such as “< fileName”, fileName may either be in a separate argument from “<” or in the same argument with no intervening space (i.e. “<fileName”).

|
  パイプライン上に並んだ命令を区切る｡先に並んだ命令の標準出力が､次の並びの命令の標準入力として手渡される｡ 　　　 Separates distinct commands in the pipeline. The standard output of the preceding command will be piped into the standard input of the next command.

|&
  パイプライン上に並んだ命令を区切る｡先に並んだ命令の､標準出力と標準不具合出力の両方が並びの次の命令の標準入力として手渡される｡この形式の出力先変更は､ 2> や >& の様な形式を上書きする｡ 　　　 Separates distinct commands in the pipeline. Both standard output and standard error of the preceding command will be piped into the standard input of the next command. This form of redirection overrides forms such as 2> and >&.

< fileName
  fileName と謂う名前のファイルが開かれ､パイプライン中の最初の命令の標準入力として使用される｡ 　　　 The file named by fileName is opened and used as the standard input for the first command in the pipeline.

<@ fileId
  fileId はそれ以前の open 呼出しの戻り値の様な､開こうとしているファイルの識別子でなければならない｡それは､パイプラインとして並んだ最初の命令の標準入力として使用される｡fileId は､予め読込み様に開けてなければならない｡ FileId must be the identifier for an open file, such as the return value from a previous call to open. It is used as the standard input for the first command in the pipeline. FileId must have been opened for reading.

<< value
  valueは系の符号化を使って符号化され､行替は系固有の行末並びに置換され､且つ､標準入力として最初の命令に渡される｡ Value is encoded using the system encoding, newlines replaced by platform-specific line ending sequences, and then passed to the first command as its standard input.

> fileName
  最後の命令の標準出力の出力先を fileName の名称のファイルに変更し､以前の内容に上書きする｡ 　　 Standard output from the last command is redirected to the file named fileName, overwriting its previous contents.

2> fileName
  パイプライン上の全ての命令の標準不具合の出力先を fileName の名称のファイルに変更し､以前の内容に上書きする｡ Standard error from all commands in the pipeline is redirected to the file named fileName, overwriting its previous contents.

>& fileName
  最後の命令の標準出力と､全ての命令の標準不具合の両方の出力先を fileName の名称のファイルに変更し､以前の内容に上書きする｡ Both standard output from the last command and standard error from all commands are redirected to the file named fileName, overwriting its previous contents.

>> fileName
  最後の命令の標準出力を fileName の名称のファイルに変更する､ファイルへの上書きではなく､末尾に追記する｡ Standard output from the last command is redirected to the file named fileName, appending to it rather than overwriting it.

2>> fileName
  パイプライン上の全ての命令の標準不具合の出力先を fileName の名称のファイルに変更する､上書きではなく､末尾に追記する｡ Standard error from all commands in the pipeline is redirected to the file named fileName, appending to it rather than overwriting it.

>>& fileName
  最後の命令の標準出力と全ての命令の標準不具合の両方の出力先を fileName の名称のファイルに変更する､上書きではなく､末尾に追記する｡ Both standard output from the last command and standard error from all commands are redirected to the file named fileName, appending to it rather than overwriting it.

>@ fileId
  fileId はそれ以前の open 呼出しの戻り値の様な､開ようとするファイルの識別子でなければならない｡最後の命令の標準出力の出力先が fileId のファイルに変更される､それは､予め書込み様に開けてなければならない｡ FileId must be the identifier for an open file, such as the return value from a previous call to open. Standard output from the last command is redirected to fileId's file, which must have been opened for writing.

2>@ fileId
  fileId はそれ以前の open 呼出しの戻り値の様な､開けようとするファイルの識別子でなければならない｡パイプライン上の全ての命令の標準不具合の出力先が fileId のファイルに変更される｡そのファイルは､予め書込み様に開けてなければならない｡ FileId must be the identifier for an open file, such as the return value from a previous call to open. Standard error from all commands in the pipeline is redirected to fileId's file. The file must have been opened for writing.

2>@1
  パイプライン上の全ての命令の標準不具合の出力先を命令の出力先に変更する｡この演算子は命令列の末尾でのみ有効に機能する｡ 　　　 Standard error from all commands in the pipeline is redirected to the command result. This operator is only valid at the end of the command pipeline.

>&@ fileId
  fileId はそれ以前の open 呼出しの戻り値の様な､ファイルを開く識別子でなければならない｡最後の命令の標準出力と全ての命令の標準不具合の両方の出力先が fileId のファイルに変更される｡そのファイルは､予め書込み様に開けてなければならない｡ FileId must be the identifier for an open file, such as the return value from a previous call to open. Both standard output from the last command and standard error from all commands are redirected to fileId's file. The file must have been opened for writing.

標準出力の出力先が変更されていない場合は､ “2>@1” が指定されていない限り､exec 命令はパイプラインの最後の命令からの標準出力を返す､この場合､標準不具合出力も同様に含まれる｡ パイプラインの命令の､いずれかが､異常終了､または､殺されるか､または実行が留保されている場合､exec は不具合を返し､不具合情報には､パイプラインの結果とそれに続く異常終了を説明する不具合情報を含んでいる；返り選択子 -errorcode は遭遇した最後の異常終了に関する追加情報を含むことになる｡何れかの命令がその標準不具合出力ファイルに書込み､且つ､その標準不具合出力の出力先が変更されてなく､かつ､ -ignorestderr が設定されていない場合､ exec は不具合を戻す; その不具合情報は､パイプラインの標準出力を含み､それに､(もしあれば)異常終了に関する情報が後に続き､更に､標準不具合出力が後に続く｡ 　　　 If standard output has not been redirected then the exec command returns the standard output from the last command in the pipeline, unless “2>@1” was specified, in which case standard error is included as well. If any of the commands in the pipeline exit abnormally or are killed or suspended, then exec will return an error and the error message will include the pipeline's output followed by error messages describing the abnormal terminations; the -errorcode return option will contain additional information about the last abnormal termination encountered. If any of the commands writes to its standard error file and that standard error is not redirected and -ignorestderr is not specified, then exec will return an error; the error message will include the pipeline's standard output, followed by messages about abnormal terminations (if any), followed by the standard error output.

結果や不都合情報の最後の文字が改行である場合､通常､その改行文字は､結果や不都合情報から削除される｡このことは､通常は改行で終ることのない他のTcl の戻り値と整合している｡但し､ -keepnewline が指定されている場合､後続の改行は保持される｡ If the last character of the result or error message is a newline then that character is normally deleted from the result or error message. This is consistent with other Tcl return values, which do not normally end with newlines. However, if -keepnewline is specified then the trailing newline is retained.

標準入力が “<” や “<<” や “<@” で入力元が変更されていない場合､パイプラインの最初の命令の標準入力は､応用譜の現在の標準入力から取得される｡ 　　　 If standard input is not redirected with “<”, “<<” or “<@” then the standard input for the first command in the pipeline is taken from the application's current standard input.

最後の引数 arg が “&” である場合は､パイプラインは､背景処理で実行される｡この場合には exec 命令は､そのパイプライン内の全ての副手続に関する手続き識別子が要素になっているリストを返す｡パイプラインの最後の命令からの標準出力は､出力先が変更されていない限り､応用譜の標準出力に移動され､パイプライン内のすべての命令からの不具合出力は､出力先が変更されていない限り､応用譜の標準不具合出力ファイルに移動する｡ 　　　 If the last arg is “&” then the pipeline will be executed in background. In this case the exec command will return a list whose elements are the process identifiers for all of the subprocesses in the pipeline. The standard output from the last command in the pipeline will go to the application's standard output if it has not been redirected, and error output from all of the commands in the pipeline will go to the application's standard error file unless redirected.

各命令の最初の単語が命令名として扱われる; 結果が斜線を含まない場合､現在のディレクトリーから､実行可能域を参照せねばならない｡名前に斜線記号が含まれている場合､現在のディレクトリから届く範囲にある実行可能な対象を指していなければならない｡この命令の引数には､ “展開” 拡張や､他の対話型実行環境の様な置換は実施されない｡ The first word in each command is taken as the command name; if the result contains no slashes then the directories in the PATH environment variable are searched for an executable by the given name. If the name contains a slash then it must refer to an executable reachable from the current directory. No “glob” expansion or other shell-like substitutions are performed on the arguments to commands.

### 互換性の問題 PORTABILITY ISSUES

Windows (all versions)
  “@ fileId” 記法を使っての､ソケットに対する読込み､書込みは､使えない｡ソケットから読込うとすると､16-bit DOS 応用譜は進行が固ってしまい､32-bit 応用譜はファイル終末状態を検知して､即座に戻ってしまう｡又､ソケットへ書込むどの型の応用譜も､情報はソケットではなく制御卓に送られるか､それが無いと棄てられる｡ 　　　　　　　 Reading from or writing to a socket, using the “@ fileId” notation, does not work. When reading from a socket, a 16-bit DOS application will hang and a 32-bit application will return immediately with end-of-file. When either type of application writes to a socket, the information is instead sent to the console, if one is present, or is discarded.

  註意すべきは現在の windows 用の引数を引用している除外表現は､ CommandLineToArgv や CRT-library 等の同等品を使うときのみ windows バッチファイルと同じように実行できる(改行 を除く､下記参照)｡ 共通の除外手順であるにも拘らず､実際は 実行譜が如何に命令行(一個の引数に分離して表現される)を解析するかの方法が決定的に重要である｡　　　　 Note that the current escape resp. quoting of arguments for windows works only with executables using CommandLineToArgv, CRT-library or similar, as well as with the windows batch files (excepting the newline, see below). Although it is the common escape algorithm, but, in fact, the way how the executable parses the command-line (resp. splits it into single arguments) is decisive.

  残念ながら､現在の処バッチファイル(.cmd か .bat)や命令処理機能(cmd.exe /c)に改行文字を提供する方法がない､理由はこれにより最初の改行文字上で命令行(及び引数連鎖も)の切詰めが生じるためである｡しかし(CommandLineToArgv 等を使う)実行譜では適切に稼働する｡　　　　　 Unfortunately, there is currently no way to supply newline character within an argument to the batch files (.cmd or .bat) or to the command processor (cmd.exe /c), because this causes truncation of command-line (also the argument chain) on the first newline character. But it works properly with an executable (using CommandLineToArgv, etc).

  Argument quoting

    exec 命令の引数は呼出される算譜の引数に対応付けされる｡必要なら､追加の引用文字(")が自動的に引数の周りに附加される｡特別な文字は逆斜線を挿入して除外される｡ The arguments of the exec command are mapped to the arguments of the called program. Additional quote characters (") are automatically added around arguments if expected. Special characters are escaped by inserting backslash characters.

    MS-Windows の環境は､引数の中に記述された実行算譜を遂行し､呼ばれたバッチファイルは環境変数(conspec⇒comspec)を置換えるが､それは副作用があり得たり(傷付き易い)､既存の何かの引用を壊し得る(譬えば､環境変数が " の様な特別の文字を含んでいる場合)｡譬えば: The MS-Windows environment does execute programs mentioned in the arguments and called batch files (conspec) replace environment variables, which may have side effects (vulnerabilities) or break any already existing quoting (for example, if the environment variable contains a special character like a "). Examples are:

        % exec my-echo.cmd {test&whoami}
          test
          mylogin
        % exec my-echo.cmd "ENV X:%X%"
          ENV X: CONTENT OF X

    副算譜の実行を避ける為に､どの引数品目の上でも､次の書式化が自動的に遂行される: 特別の文字 (&, |, ^, <, >, !, (, ), (, %) を含んでいるどの特別文字引数も自動的に引用符 (") 内に囲まれる｡どのデータ引用も逆斜線文字の挿入により除外される｡ The following formatting is automatically performed on any argument item to avoid subprogram execution: Any special character argument containing a special character (&, |, ^, <, >, !, (, ), (, %) is automatically enclosed in quotes ("). Any data quote is escaped by insertion of backslash characters.

    "%var%" を使用する環境変数の自動的解析は際どいが､危険な使用と除外不使用よりも使われる｡ The automatic resolving of environment variables using "%var%" is critical, but has more use than danger and is not escaped.

  Tk の制御窓 text 部品は実際の標準入出力実行能力を提供できない｡Tk の下では､標準入力の入力元変更がされると､全ての応用譜で即座にファイル終末状態を検知する;標準出力や標準不都合出力に出力先変更された情報は棄てられることになる｡ 　　　 The Tk console text widget does not provide real standard IO capabilities. Under Tk, when redirecting from standard input, all applications will see an immediate end-of-file; information redirected to standard output or standard error will be discarded.

  Tcl 命令への引数ではファイル経路の区切りには順斜線でも逆斜線でも使用できる｡応用譜を実行させる場合も､応用譜の入っている場所の区切りは順斜線でも逆斜線でもよい｡留意すべきことに､殆どの Windows 応用譜では､指示項目の区切には順斜線のみが､ファイル経路の区切には逆斜線のみが使用できる｡応用譜への何れの引数に於いても､順斜線を使ったファイル経路の指定が自動的に逆斜線記号を使用したものに変更されはしない｡ファイル経路の区切として順斜線を含む引数が､意図どおりに認識されるか否かはそのプログラム次第である｡ 　　　 Either forward or backward slashes are accepted as path separators for arguments to Tcl commands. When executing an application, the path name specified for the application may also contain forward or backward slashes as path separators. Bear in mind, however, that most Windows applications accept arguments with forward slashes only as option delimiters and backslashes only in paths. Any arguments to an application that specify a path name with forward slashes will not automatically be converted to use the backslash character. If an argument contains forward slashes as the path separator, it may or may not be recognized as a path name, depending on the program.

  経路の中の二つ以上の連続した順斜線又は逆斜線の並びは電網上の経路を参照する｡譬えば､大元のディレクトリ c:/ に下位ディレクトリ /windows/system を単純に繋げると､ c://windows/system (二つの斜線が入る)になるが､このものはwindows に呼出された装置上の system に呼出された搭載位置を参照しており(あの c:/ は無視される) 現在の装置のディレクトリーとして記述された c:/windows/system とは異なっている｡経路の断片からの組立てには､ file join 命令を使用することが望ましい｡ Two or more forward or backward slashes in a row in a path refer to a network path. For example, a simple concatenation of the root directory c:/ with a subdirectory /windows/system will yield c://windows/system (two slashes together), which refers to the mount point called system on the machine called windows (and the c:/ is ignored), and is not equivalent to c:/windows/system, which describes a directory on the current computer. The file join command should be used to concatenate path components.

  註意 Win32 黒窓応用譜は二つの一般化型がある: 　　 Note that there are two general types of Win32 console applications:

  1. CLI — 命令行対話機能(CommandLine Interface の略), 単純な標準入出力対話機能｡ netstat.exe 等がその例である｡ 　 CLI — CommandLine Interface, simple stdio exchange. netstat.exe for example.

  2. TUI — 文書様式機能(Textmode User Interfaceの略) ､遊走子の移動､文字の着色､打鍵の検知､マウスの移動､等､の動作を行う為の操作卓利用規約に接見する種々の応用譜｡元々 Windows 2000用に開発された telnet.exe が代表例である｡ この型の応用譜は windows の環境では一般的ではないが､幾つかが存在する｡　　　　　　　　 TUI — Textmode User Interface, any application that accesses the console API for doing such things as cursor movement, setting text color, detecting key presses and mouse movement, etc. An example would be telnet.exe from Windows 2000. These types of applications are not common in a windows environment, but do exist.

  黒窓が開いていないときには､ TUI 応用譜を伴う exec は､wish の下で応用譜を開始する時の様には､上手くは動かないであろう｡応用譜に､黒窓を隠させ､切離させることが望ましい｡ exec がパイプを介して通信しようとするので､これが､設計上の限界である｡Expect 拡張(訳注 拡張Tclの一種)は､TUI 応用譜と通信する場合､この問題を扱う｡ exec will not work well with TUI applications when a console is not present, as is done when launching applications under wish. It is desirable to have console applications hidden and detached. This is a designed-in limitation as exec wants to communicate over pipes. The Expect extension addresses this issue when communicating with a TUI application.

  応用譜の実行を試みる場合､exec は､最初に､指定された名前をそのままで探索する｡次に順番に､.com､.exe､.bat､.cmd を指定された名前の末尾に添付して､長い名前を探索する｡ディレクトリ名が応用譜名の一部として指定されなかった場合は､応用譜の在所を見つける為に､次のディレクトリーが自動的に順番に探索される: 　 　 When attempting to execute an application, exec first searches for the name as it was specified. Then, in order, .com, .exe, .bat and .cmd are appended to the end of the specified name and it searches for the longer name. If a directory name was not specified as part of the application name, the following directories are automatically searched in order when attempting to locate the application:

  - Tcl の実行可能ファイルが組込まれたディレクトリ｡ 　　 The directory from which the Tcl executable was loaded.

  - 現在のディレクトリ｡ 　　　 The current directory.

  - Windows NT の32ビットシステムディレクトリ｡ 　　　 The Windows 32-bit system directory.

  - Windows の自宅ディレクトリ｡ 　　　 The Windows home directory.

  - 経路に列挙されているディレクトリ｡ 　　　 The directories listed in the path.

  組込み命令が実行可能ファイルを使用して実装されていないため､組込みの dir や copy のようなシェル組込み命令を実行するためには､呼出し元は､ “cmd.exe /c ” を､目的の命令の前に付加する必要がある｡ 　　　 In order to execute shell built-in commands like dir and copy, the caller must prepend the desired command with “cmd.exe /c ” because built-in commands are not implemented using executables.

Unix (including macOS)
  exec 命令は完全に機能し､記述した通りに動作する｡ 　　 The exec command is fully functional and works as described.

### UNIX 実施例 UNIX EXAMPLES

此処にあるのは､Unix 上で exec 命令を使用する幾つかの例である｡簡単なプログラムを実行してその結果を得る: 　　　 Here are some examples of the use of the exec command on Unix. To execute a simple program and get its result:

    exec uname -a

#### 非零の結果を返す場合 WORKING WITH NON-ZERO RESULTS

非零の結果を返すかもしれないプログラムを実行する為には､ exec の呼出を catch 命令に包込み､不具合が生じたら､return 命令の -errorcode 指定の内容を確認する事が好ましい: 　　　 To execute a program that can return a non-zero result, you should wrap the call to exec in catch and check the contents of the -errorcode return option if you have an error:

    set status 0
    if {[catch {exec grep foo bar.txt} results options]} {
        set details [dict get $options -errorcode]
        if {[lindex $details 0] eq "CHILDSTATUS"} {
            set status [lindex $details 2]
        } else {
            # Some other error; regenerate it to let caller handle
            return -options $options -level 0 $results
        }
    }

try 命令を使うと､特定の型の不具合の捕捉を容易にさせるので､もっと容易に書ける｡命令符号をこのように使って達成できる:　 　　　 This is more easily written using the try command, as that makes it simpler to trap specific types of errors. This is done using code like this:

    try {
        set results [exec grep foo bar.txt]
        set status 0
    } trap CHILDSTATUS {results options} {
        set status [lindex [dict get $options -errorcode] 2]
    }

#### 引用記号のある引数を使う　WORKING WITH QUOTED ARGUMENTS

Unix シェル呼び出しから命令を翻訳する時に註意すべきことは､一重引用記号はTclでは､特別の意味を持たないことである｡従ってこれは:　　　　　　 When translating a command from a Unix shell invocation, care should be taken over the fact that single quote characters have no special significance to Tcl. Thus:

    awk '{sum += $1} END {print sum}' numbers.list

は､何か次のように翻訳されるべきである: 　　　 would be translated into something like:

    exec awk {{sum += $1} END {print sum}} numbers.list

#### 展開を含む稼働 WORKING WITH GLOBBING

もし､シェルの展開を含む起動を変換する時は､Tclは省略時設定では､展開や､何かを複数の引数に入れる拡張は扱わないことを念頭に置くべきである｡代りに､次のように書くべきであろう: If you are converting invocations involving shell globbing, you should remember that Tcl does not handle globbing or expand things into multiple arguments by default. Instead you should write things like this:

    exec ls -l {*}[glob *.tcl]

#### 使用者が提供する対話記述譜断片で WORKING WITH USER-SUPPLIED SHELL SCRIPT FRAGMENTS

使用者に､一つの便利な技術が陳列できる､それは､Tcl 算譜によって生成された何かのデータを標準入力上に通過させることを実行する為のシェル記述譜の断片を指定することができる記述譜の技術である｡これは印刷の為の lpr 算譜を使う為の共通の技巧である｡最簡易な方法の実行とは程遠く､これを実行するには使用者の記述譜を使用者の対話譜に処理の為に渡し､他の言語の解析による多くの複雑さを回避する｡ One useful technique can be to expose to users of a script the ability to specify a fragment of shell script to execute that will have some data passed in on standard input that was produced by the Tcl program. This is a common technique for using the lpr program for printing. By far the simplest way of doing this is to pass the user's script to the user's shell for processing, as this avoids a lot of complexity with parsing other languages.

    set lprScript [get from user...]
    set postscriptData [generate somehow...]

    exec $env(SHELL) -c $lprScript << $postscriptData

### Windows での実施例　WINDOWS EXAMPLES

ここに､ウィンドウズで exec 命令を使う幾つかの例を示す｡使用者がファイルを編集し終えるのを待たずに､ファイルを編集するノートパッドの実使用を開始する: Here are some examples of the use of the exec command on Windows. To start an instance of notepad editing a file without waiting for the user to finish editing the file:

    exec notepad myfile.txt &

ノートパッドを使用して､テキストファイルを印刷する: To print a text file using notepad:

    exec notepad /p myfile.txt

#### タイプ入力画面から使う WORKING WITH CONSOLE PROGRAMS

譬えば言語翻訳でよく行われる様に､プログラムが他のプログラムを呼出す場合には､時折開く黒窓を隠す為に､バッチファイルに訴える必要があるかもしれない: 　　　　 If a program calls other programs, such as is common with compilers, then you may need to resort to batch files to hide the console windows that sometimes pop up:

    exec cmp.bat somefile.c -o somefile

何か次の様なファイル cmp.bat を使う: 　　　　 With the file cmp.bat looking something like:

    @gcc %*

又は､一個の假引数を使う別のやりかた:　　　 or like another variant using single parameters:

    @gcc %1 %2 %3 %4 %5 %6 %7 %8 %9

#### 組込み命令を使う WORKING WITH COMMAND BUILT-INS

時には､異なる算譜が同じ名前を持ってその経路内に存在するかもしれないので､注意を要する｡ DOS 入力催促印に鍵盤入力された命令は､ exec によって実行された同じ命令とは異なるプログラムを偶然見つける場合がありえる｡理由は､ exec とDOSのバッチファイルでは(文書化された)振舞いが違うためである｡ Sometimes you need to be careful, as different programs may have the same name and be in the path. It can then happen that typing a command at the DOS prompt finds a different program than the same command run via exec. This is because of the (documented) differences in behaviour between exec and DOS batch files.

不確かな時には､auto_execok 命令を使用されたい:それは､ exec 命令に見付けられたプログラムへの完全な経路を返す｡（ファイル名を列挙したい時に､ glob 命令を使う如く）之は､Tcl 記述譜から､ dir の様な “内部” 命令を走らせたい時に特に適用する｡その為に､この様に使う: 　　　　 When in doubt, use the command auto_execok: it will return the complete path to the program as seen by the exec command. This applies especially when you want to run “internal” commands like dir from a Tcl script (if you just want to list filenames, use the glob command.) To do that, use this:

    exec {*}[auto_execok dir] *.tcl

#### 元々のファイル名を使う WORKING WITH NATIVE FILENAMES

Windows 上の多くの算譜は渡されるファイル名引数に経路名の区切りとして逆斜線を要求する｡これは file nativename 命令の助けによって遂行される｡譬えば､現在の使用者のみが利用できる暗号化されたディレクトリーを( NTFS 上に)作る為には､ CIPHER 命令の使用を要求する､このように: Many programs on Windows require filename arguments to be passed in with backslashes as pathname separators. This is done with the help of the file nativename command. For example, to make a directory (on NTFS) encrypted so that only the current user can access it requires use of the CIPHER command, like this:

    set secureDir [file join [file home] Desktop/SecureDirectory]
    file mkdir $secureDir
    exec CIPHER /e /s:[file nativename $secureDir]

### SEE ALSO

error, file, open

### KEYWORDS

execute, pipeline, redirection, subprocess
Copyright © 1993 The Regents of the University of California.
Copyright © 1994-1996 Sun Microsystems, Inc.
Copyright © 2006 Donal K. Fellows.