exec(3tcl) | Tcl Built-In Commands | exec(3tcl) |
NAME¶
exec - 調用子進程總覽 SYNOPSIS¶
exec ?switches? arg ?arg ...?描述 DESCRIPTION¶
這個命令把它的參數作為對要執行的一個或多個子進程的指定來對待。參數接受標準的 shell 管道的格式(form),即每個 arg 都變成某個命令的一個字,並且每個不同的命令都變成一個子進程。 如果給 exec的初始的參數以 - 開始,則它們被作為命令行開關而不是管道指定的一部分來對待。當前支持下列開關:- -keepnewline
- 在管道的輸出中保持尾隨的換行符。通常要刪除尾隨的換行符。
- --
- 標誌開關(部分)的結束。此後的參數即使以-開頭仍被作為第一個 arg 來對待。
- |
- 分隔在管道中不同的命令。前面的命令的標準輸出將被輸送給後面命令的標準輸入中。
- |&
- 分隔在管道中不同的命令。前面命令的標準輸出和標準錯誤輸出都被輸送到後面的標準輸入中。這種重定向格式取代像 2> 和 >& 這樣的格式。
- < fileName
- 打開由 fileName 指名的檔案並作為在管道中的第一個命令的標準輸入來使用。
- <@ fileId
- FileId
必須是一個打開了的檔案的標識符,比如是從以前的
open
調用的返回值。作為在管道中的第一個命令的標準輸入來使用。
FileId
必須用讀模式來打開。
- << value
- Value 被傳遞給第一個命令來作為它的標準輸入。
- > fileName
- 最後的命令的標準輸出被重定向到叫 fileName 的檔案中,覆蓋它以前的內容。
- 2> fileName
- 把管道中所有命令的標準錯誤輸出重定向到叫 fileName 的檔案中,覆蓋它以前的內容。
- >& fileName
- 最後的命令的標準輸出和所有命令的標準錯誤輸出都被重定向到叫 fileName的檔案中,覆蓋它以前的內容。
- >> fileName
- 最後的命令的標準輸出被重定向到叫 fileName 的檔案中,對它進行添加而不是覆蓋它。
- 2>> fileName
- 在管道中的所有的命令的標準錯誤輸出都被重定向到叫 fileName的檔案中,對它進行添加而不是覆蓋它。
- >>& fileName
- 最後的命令的標準輸出和所有命令的標準錯誤輸出被重定向到叫 fileName 的檔案中,對它進行添加而不是覆蓋它。
- >@ fileId
- FileId 必須是一個打開了的檔案的標識符,比如是從以前的 open調用的返回值。最後的命令的標準輸出被重定向到 fileId(指定)的檔案中。檔案必須用讀模式來打開。
- 2>@ fileId
- FileId 必須是一個打開了的檔案的標識符,比如是從以前的 open調用的返回值。在管道中的所有命令的標準錯誤輸出都被重定向到 fileId(指定)的檔案中。檔案必須用寫模式來打開。
- >&@ fileId
- FileId 必須是一個打開了的檔案的標識符,比如是從以前的 open調用的返回值。最後的命令的標準輸出和所有命令的標準錯誤輸出被重定向到 fileId(指定)的檔案中。檔案必須用寫模式來打開。
移植要點 PORTABILITY ISSUES¶
- Windows (所有版本)
- 從/向一個套接口讀或寫,使用「@ fileId」記號(notation),不能工作。在從一個套接口讀的時候,一個16位 DOS 應用程式將掛起(hang) 而一個32位應用程式將立即返回檔案結束(end-of-file)。在任意類型的應用向一個套接口寫的時候,如果控制台存在的話,信息轉而發送到控制台,否則就丟棄信息。 Tk 控制台文本組件不提供真實的標準 IO 功能。在 Tk 下,從標準輸入重定向的時候,所有的應用將看到一個立即的檔案結束;重定向到標準輸出或標準錯誤輸出的信息將被丟棄。 要麼是正斜槓要麼是反斜槓被接受為給 Tcl 命令的參數的路徑分隔符。在執行一個應用的時候,對應用的路徑名指定也可以包含正或反斜槓作為路徑分隔符。但是必須記住,多數 Windows 應用接受有正斜槓的參數作為選項分界符(delimiter)而反斜槓只在路徑中。指定了有正斜槓的一個路徑名的給應用的任何參數將不被自動的轉換成使用反斜槓字符。如果一個參數包括作為路徑分隔符的正斜槓,它可以被識別成路徑名,也可以不被識別成路徑名,這依賴於(具體)程式。 額外的,在調用一個16位 DOS 或 Windows 3.X 應用時,所有路徑名必須使用短的、神秘的(cryptic)的路徑格式(例如,使用「applba~1.def」來替代 「applbakery.default」)。 在一個路徑中在一行的兩個或更多的正或反斜槓參照一個網路路徑。例如,根目錄 c:/ 和一個子目錄/windows/system的一個簡單的連接將產生 c://windows/system (兩個斜槓在一起),這參照的是在叫 windows 的那台機器上的叫 system 的掛裝點(而 c:/ 被忽略),這並不等價於 c:/windows/system,它描述的是在當前電腦上的一個目錄。應使用 file join 命令來連接路徑的成員。
- Windows NT
- 在嘗試執行一個應用時,exec 首先查找指定的那個名字。接著按 .com、 .exe, 和 .bat 的次序把它們添加到指定的名字的後面並查找這個加長了的名字。如果沒有指定一個目錄名作為應用(程式)名的一部分,在嘗試定位應用(程式)時,依次在下列目錄中自動查找:
裝載 Tcl
可執行檔案的目錄。
當前目錄
Windows NT 32位系統目錄。
Windows NT 16位系統目錄。
Windows NT 主目錄。
在 path 中列出的目錄。
要執行 shell 內置命令像
dir 和 copy,
調用者必須為想用的命令加上「
cmd.exe /c 」前導 (prepend)。
- Windows 95
- 在嘗試執行一個應用時,exec首先查找指定的那個名字。接著按 .com、 .exe, 和 .bat 的次序把它們添加到指定的名字的後面並查找這個加長了的名字。如果沒有指定一個目錄名作為應用(程式)名的一部分,在嘗試定位應用(程式)時,依次在下列目錄中自動查找:
裝載 Tcl
可執行檔案的目錄。
當前目錄。
Windows 95 系統目錄。
Windows 95 主目錄。
在 path 中列出的目錄。
要執行 shell 內置命令像
dir 和 copy,
調用者必須為想用的命令加上「
command.exe /c 」前導(prepend)。
一旦一個 16位 DOS
應用程式從一個控制台讀標準輸入接著退出,所以後來運行的
16位 DOS
應用程式將看到標準輸入已經被關閉了。32位應用程式沒有這個問題並將正確運行,即使在一個
16位 DOS
應用程式認為標準輸入已經被關閉之後。此時還沒有針對這個缺陷的已知的工作項目(workaround)。
NUL: </B> 設備和一個
16位應用程式之間的重定向不總是工作。在從
NUL: 重定向時
一些應用程式可能掛起,另一些將得到永無窮盡(infinite)的「0x01」字節流(stream),而有一些實際上將正確的得到立即的檔案結束;這些行為像是依賴於編譯到應用程式自身中的某些東西。在到
NUL:的重定向大於或等於4K
時,
一些應用將掛起(hang)。在32位應用程式中不發生上述問題。
所有 DOS
16位應用程式都是同步運行的。從一個管道到一個
16位 DOS
應用程式的所有標準輸入被搜集到一個臨時檔案中;在這個16位
DOS
應用程式開始執行之前,管道的其他端點(end)必須被關閉。從一個16位
DOS應用程式到一個管道的所有標準輸出或錯誤輸出被搜集到一個臨時檔案中;在臨時檔案被重定向到管道的下一個階段之前,這個應用程式必須終止。這源於一個針對
Windows
95在實現管道中的一個缺陷的工作項目,也是標準的
Windows 95 DOS shell
自身處理管道的方式。
特定的應用程式,像
command.com
,不應該交互的執行。不從標準輸入讀和向標準輸出寫,而是直接訪問控制台視窗的應用程式可能會失敗,並掛起Tcl,如果它們自己的私有控制台視窗不可使用甚至可能掛起系統。- Macintosh
- 在 Macintosh 下 exec 命令未被實現而不存在。
- Unix
-
exec 命令是全功能的並像上面描述的那樣工作。
參見 SEE ALSO¶
error(n), open(n)關鍵字 KEYWORDS¶
execute, pipeline, redirection, subprocess[中文版維護人]¶
寒蟬退士[中文版最新更新]¶
2001/07/11《中國 Linux 論壇 man 手冊頁翻譯計劃》:¶
http://cmpp.linuxforum.net7.6 | Tcl |