exec(3tcl) | Tcl Built-In Commands | exec(3tcl) |
exec - 调用子进程
exec ?switches? arg ?arg ...?
这个命令把它的参数作为对要执行的一个或多个子进程的指定来对待。参数接受标准的 shell 管道的格式(form),即每个 arg 都变成某个命令的一个字,并且每个不同的命令都变成一个子进程。
如果给 exec的初始的参数以 - 开始,则它们被作为命令行开关而不是管道指定的一部分来对待。当前支持下列开关:
如果一个 arg (或成对的 arg)有象下面描述的格式个某一种,则exec 用它来控制子进程间的输入和输出流(flow)。将不把这样的参数传递给子进程。在象“< fileName”这样的格式中 fileName 可以要么是一个与“<”分离的参数,要么是在同一个参数中而没有间隔的空格(例如 “<fileName”)。
如果标准输出没有被重定向,则 exec 命令返回在管道中最后的命令的标准输出。如果在管道中的任何命令不正常退出或被杀死或被挂起,则 exec 将返回一个错误和并且错误信息将包含管道的输出和随后的描述不正常终止的错误信息;errorCode 变量将包括关于最近所遭遇的不正常终止的额外的信息。如果任何命令写它的标准错误文件而这个标准错误未被重定向,则 exec 将返回一个错误;错误消息将包含管道的标准输出,跟着是关于不正常终止的信息(如果有的话),随后是标准错误输出。
如果结果或错误信息的最后的字符是一个换行符,则这个换行符通常被从结果或错误信息中删除。这是与其他 Tcl 返回值相一致的,它们通常不用换行(作为)结束。但是,如果指定了 -keepnewline则保持尾随的换行符。
如果标准输入未使用 “<” 、“<<” 或 “<@” 来重定向,则把应用的当前的标准输入作为第一个命令的标准输入。
如果最后的 arg 是“&”,则管道将在后台执行。在这种情况下 exec命令将返回一个列表,列表的元素是在管道中所有子进程的进程标识符。如果在管道中最后的命令的标准输出未被重定向,则输出到应用的标准输出中,并且如果管道中所有的命令的错误输出未被重定向,则错误输出到应用的标准错误中。
每个命令中的第一个字被接受为命令的名字;在它上面进行“~”(tilde)替换,如果结果不包含斜杠,则在 PATH 环境变量中的目录里查找给定名字的可执行文件。如果名字包含斜杠,则它必须参照一个从当前目录可到达的可执行文件。在给命令的参数上不进行通配符 (glob) 扩展或其他的 shell 式的替换。
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 命令来连接路径的成员。
要执行 shell 内置命令象 dir 和 copy, 调用者必须为想用的命令加上“cmd.exe /c ”前导 (prepend)。
要执行 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,如果它们自己的私有控制台窗口不可使用甚至可能挂起系统。
error(n), open(n)
execute, pipeline, redirection, subprocess
寒蝉退士
2001/07/11
http://cmpp.linuxforum.net
本页面中文版由中文
man 手册页计划提供。
中文 man
手册页计划:https://github.com/man-pages-zh/manpages-zh
7.6 | Tcl |