|
一、概述 我们通过Shell可以实现简单的控制流功能，如：循环、判断等。但是对于需要 交互的场合则必须通过人工来干预，有时候我们可能会需要实现 和交互程序如telnet服务器等进行交互的功能。而Expect就使用来实现这种功能 的工具。 Expect是一个免费的编程工具语言，用来实现自动和交互式任务进行通信，而无 需人的干预。Expect的作者Don Libes在1990年开始编写Expect时对Expect做有如下定义：Expect是一个用来实 现自动交互功能的软件套件(Expect [is a] software suite for automating interactive tools)。使用它系统管理员的可以创建脚本用来实现对命令或程序提供输入，而 这些命令和程序是期望从终端（terminal）得到输入，一般来 说这些输入都需要手工输入进行的。Expect则可以根据程序的提示模拟标准输入 提供给程序需要的输入来实现交互程序执行。甚至可以实现实 现简单的BBS聊天机器人。 Expect是不断发展的，随着时间的流逝，其功能越来越强大，已经成为系统管理 员的的一个强大助手。Expect需要Tcl编程语言的支持，要在系 统上运行Expect必须首先安装Tcl。 二、Expect工作原理 从最简单的层次来说，Expect的工作方式象一个通用化的Chat脚本工具。Chat脚 本最早用于UUCP网络内，以用来实现计算机之间需要建立连接 时进行特定的登录会话的自动化。 Chat脚本由一系列expect-send对组成：expect等待输出中输出特定的字符，通 常是一个提示符，然后发送特定的响应。例如下面的Chat脚本实 现等待标准输出出现Login:字符串，然后发送somebody作为用户名；然后等待Pa ssword:提示符，并发出响应sillyme。 QUOTE: Login: somebody Password: sillyme 这个脚本用来实现一个登录过程，并用特定的用户名和密码实现登录。 Expect最简单的脚本操作模式本质上和Chat脚本工作模式是一样的。 例子： 1、实现功能 下面我们分析一个响应chsh命令的脚本。我们首先回顾一下这个交互命令的格式 。假设我们要为用户chavez改变登录脚本，要求实现的命令交 互过程如下： QUOTE: # chsh chavez Changing the login shell for chavez Enter the new value, or press return for the default Login Shell [/bin/bash]: /bin/tcsh # 可以看到该命令首先输出若干行提示信息并且提示输入用户新的登录shell。我 们必须在提示信息后面输入用户的登录shell或者直接回车不修 改登录shell。 2、下面是一个能用来实现自动执行该命令的Expect脚本： CODE:[Copy to clipboard]#!/usr/bin/expect # Change a login shell to tcsh set user [lindex $argv 0] spawn chsh $user expect "]:" send "/bin/tcsh " expect eof exit 这个简单的脚本可以解释很多Expect程序的特性。和其他脚本一样首行指定用来 执行该脚本的命令程序，这里是/usr/bin/expect。程序第一行 用来获得脚本的执行参数(其保存在数组$argv中，从0号开始是参数)，并将其保 存到变量user中。 第二个参数使用Expect的spawn命令来启动脚本和命令的会话，这里启动的是chs h命令，实际上命令是以衍生子进程的方式来运行的。 随后的expect和send命令用来实现交互过程。脚本首先等待输出中出现]:字符串 ，一旦在输出中出现chsh输出到的特征字符串(一般特征字符串 往往是等待输入的最后的提示符的特征信息)。对于其他不匹配的信息则会完全 忽略。当脚本得到特征字符串时，expect将发送/bin/tcsh和一 个回车符给chsh命令。最后脚本等待命令退出(chsh结束)，一旦接收到标识子进 程已经结束的eof字符，expect脚本也就退出结束。 3、决定如何响应 管理员往往有这样的需求，希望根据当前的具体情况来以不同的方式对一个命令 进行响应。我们可以通过后面的例子看到expect可以实现非常 复杂的条件响应，而仅仅通过简单的修改预处理脚本就可以实现。下面的例子是 一个更复杂的expect-send例子： CODE:[Copy to clipboard]expect -re "[(.*)]:" if {$expect_out(1,string)!="/bin/tcsh"} { send "/bin/tcsh" } send " " expect eof 在这个例子中，第一个expect命令现在使用了-re参数，这个参数表示指定的的 字符串是一个正则表达式，而不是一个普通的字符串。对于上面 这个例子里是查找一个左方括号字符(其必须进行三次逃逸(escape)，因此有三 个符号，因为它对于expect和正则表达时来说都是特殊字符)后 面跟有零个或多个字符，最后是一个右方括号字符。这里.*表示表示一个或多个 任意字符，将其存放在()中是因为将匹配结果存放在一个变量 中以实现随后的对匹配结果的访问。 当发现一个匹配则检查包含在[]中的字符串，查看是否为/bin/tcsh。如果不是 则发送/bin/tcsh给chsh命令作为输入，如果是则仅仅发送一个 回车符。这个简单的针对具体情况发出不同相响应的小例子说明了expect的强大 功能。 在一个正则表达时中，可以在()中包含若干个部分并通过expect_out数组访问它 们。各个部分在表达式中从左到右进行编码，从1开始(0包含有 整个匹配输出)。()可能会出现嵌套情况，这这种情况下编码从最内层到最外层 来进行的。 4、使用超时 下一个expect例子中将阐述具有超时功能的提示符函数。这个脚本提示用户输入 ，如果在给定的时间内没有输入，则会超时并返回一个默认的 响应。这个脚本接收三个参数：提示符字串，默认响应和超时时间(秒)。 CODE:[Copy to clipboard]#!/usr/bin/expect # Prompt function with timeout and default. set prompt [lindex $argv 0] set def [lindex $argv 1] set response $def set tout [lindex $argv 2] 脚本的第一部分首先是得到运行参数并将其保存到内部变量中。 CODE:[Copy to clipboard]send_tty "$prompt: " set timeout $tout expect " " { set raw $expect_out(buffer) # remove final carriage return set response [string trimright "$raw" " "] } if {"$response" == "} {set response $def} send "$response " # Prompt function with timeout and default. set prompt [lindex $argv 0] set def [lindex $argv 1] set response $def set tout [lindex $argv 2] 这是脚本其余的内容。可以看到send_tty命令用来实现在终端上显示提示符字串 和一个冒号及空格。set timeout命令设置后面所有的expect命令的等待响应的超时时间为$tout(-l参数 用来关闭任何超时设置)。 然后expect命令就等待输出中出现回车字符。如果在超时之前得到回车符，那么 set命令就会将用户输入的内容赋值给变脸raw。随后的命令将 用户输入内容最后的回车符号去除以后赋值给变量response。 然后，如果response中内容为空则将response值置为默认值(如果用户在超时以 后没有输入或者用户仅仅输入了回车符)。最后send命令将respo nse变量的值加上回车符发送给标准输出。 一个有趣的事情是该脚本没有使用spawn命令。 该expect脚本会与任何调用该脚本的进程交互。 如果该脚本名为prompt，那么它可以用在任何C风格的shell中。 % set a='prompt "Enter an answer" silence 10' Enter an answer: test % echo Answer was "$a" Answer was test prompt设定的超时为10秒。如果超时或者用户仅仅输入了回车符号，echo命令将 输出 Answer was "silence" 5、一个更复杂的例子 下面我们将讨论一个更加复杂的expect脚本例子，这个脚本使用了一些更复杂的 控制结构和很多复杂的交互过程。这个例子用来实现发送write 命令给任意的用户，发送的消息来自于一个文件或者来自于键盘输入。 CODE:[Copy to clipboard]#!/usr/bin/expect # Write to multiple users from a prepared file # or a message input interactively if {$argc;*" send "get [lindex $argv 2] " expect "*ftp>;*" 上面这个程序被设计成在后台进行ftp。虽然他们在底层使用和expect类似 的机制，但他们的可编程能力留待改进。因为expect提供了高级 语言，你可以对它进行修改来满足你的特定需求。比如说，你可以加上以下功能 ： ：坚持－－如果连接或者传输失败，你就可以每分钟或者每小时，甚 至可以根据其他因素，比如说用户的负载，来进行不定期的 重试。 ：通知－－传输时可以通过mail,write或者其他程序来通知你，甚至 可以通知失败。 ：初始化－每一个用户都可以有自己的用高级语言编写的初始化文件 (比如说，.ftprc)。这和C shell对.cshrc的使用很类似。 expect还可以执行其他的更复杂的任务。比如说，他可以使用McGill大学的 Archie系统。Archie是一个匿名的Telnet服务，它提供对描述I nternet上可通过匿名ftp获取的文件的数据库的访问。通过使用这个服务，脚本 可以询问Archie某个特定的文件的位置，并把它从ftp服务器上 取下来。这个功能的实现只要求在上面那个脚本中加上几行就可以。 现在还没有什么已知的后台-ftp能够实现上面的几项功能，能不要说所有的 功能了。在expect里面，它的实现却是非常的简单。“坚持”的 实现只要求在expect脚本里面加上一个循环。“通知”的实现只要执行mail和wr ite就可以了。“初始化文件”的实现可以使用一个命令，source .ftprc，就可以了，在.ftprc里面可以有任何的expect命令。 虽然这些特征可以通过在已有的程序里面加上钩子函数就可以，但这也不能 保证每一个人的要求都能得到满足。唯一能够提供保证的方法 就是提供一种通用的语言。一个很好的解决方法就是把Tcl自身融入到ftp和其他 的程序中间去。实际上，这本来就是Tcl的初衷。在还没有这样 做之前，expect提供了一个能实现大部分功能但又不需要任何重写的方案。 9.[fsck] fsck是另外一个缺乏足够的用户接口的例子。fsck几乎没有提供什么方法来 预先的回答一些问题。你能做的就是给所有的问题都回答"yes" 或者都回答"no"。 下面的程序段展示了一个脚本如何的使的自动的对某些问题回答"yes"，而 对某些问题回答"no"。下面的这个脚本一开始先派生fsck进程， 然后对其中两种类型的问题回答"yes"，而对其他的问题回答"no"。 for {} {1} {} { expect eof break "*UNREF FILE*CLEAR?" {send "r "} "*BAD INODE*FIX?" {send "y "} "*?" {send "n "} } 在下面这个版本里面，两个问题的回答是不同的。而且，如果脚本遇到了什 么它不能理解的东西，就会执行interact命令把控制交给用户 。用户的击键直接交给fsck处理。当执行完后，用户可以通过按"+"键来退出或 者把控制交还给expect。如果控制是交还给脚本了，脚本就会自 动的控制进程的剩余部分的运行。 for {} {1} {}{ expect eof break "*UNREF FILE*CLEAR?" {send "y "} "*BAD INODE*FIX?" {send "y "} "*?" {interact +} } 如果没有expect，fsck只有在牺牲一定功能的情况下才可以非交互式的运行 。fsck几乎是不可编程的，但它却是系统管理的最重要的工具 。许多别的工具的用户接口也一样的不足。实际上，正是其中的一些程序的不足 导致了expect的诞生。 10.[控制多个进程：作业控制] expect的作业控制概念精巧的避免了通常的实现困难。其中包括了两个问题：一 个是expect如何处理经典的作业控制，即当你在终端上按下^Z 键时expect如何处理；另外一个就是expect是如何处理多进程的。 对第一个问题的处理是：忽略它。expect对经典的作业控制一无所知。比如说， 你派生了一个程序并且发送一个^Z给它，它就会停下来(这是伪 终端的完美之处)而expect就会永远的等下去。 但是，实际上，这根本就不成一个问题。对于一个expect脚本，没有必要向进程 发送^Z。也就是说，没有必要停下一个进程来。expect仅仅是 忽略了一个进程，而把自己的注意力转移到其他的地方。这就是expect的作业控 制思想，这个思想也一直工作的很好。 从用户的角度来看是象这样的：当一个进程通过spawn命令启动时，变量spa wn_id就被设置成某进程的描述符。由spawn_id描述的进程就被 认为是当前进程。(这个描述符恰恰就是伪终端文件的描述符，虽然用户把它当 作一个不透明的物体)。expect和send命令仅仅和当前进程进行 交互。所以，切换一个作业所需要做的仅仅是把该进程的描述符赋给spawn_id。 这儿有一个例子向我们展示了如何通过作业控制来使两个chess进程进行交 互。在派生完两个进程之后，一个进程被通知先动一步。在下面 的循环里面，每一步动作都送给另外一个进程。其中，read_move和write_move 两个过程留给读者来实现。(实际上，它们的实现非常的容易， 但是，由于太长了所以没有包含在这里)。 spawn chess ;# start player one set id1 $spawn_id expect "Chess " send "first " ;# force it to go first read_move spawn chess ;# start player two set id2 $spawn_id expect "Chess " for {} {1} {}{ send_move read_move set spawn_id $id1 send_move read_move set spawn_id $id2 } 有一些应用程序和chess程序不太一样，在chess程序里，的两个玩家轮流动。下 面这个脚本实现了一个冒充程序。它能够控制一个终端以便用 户能够登录和正常的工作。但是，一旦系统提示输入密码或者输入用户名的时候 ，expect就开始把击键记下来，一直到用户按下回车键。这有 效的收集了用户的密码和用户名，还避免了普通的冒充程序的"Incorrect password-tryagain"。而且，如果用户连接到另外一个主机上，那些额外的登录 也会被记录下来。 spawn tip /dev/tty17 ;# open connection to set tty $spawn_id ;# tty to be spoofed spawn login set login $spawn_id log_user 0 for {} {1} {} { set ready [select $tty $login] case $login in $ready { set spawn_id $login expect {"*password*" "*login*"}{ send_user $expect_match set log 1 } "*" ;# ignore everything else set spawn_id $tty; send $expect_match } case $tty in $ready { set spawn_id $tty expect "* *"{ if $log { send_user $expect_match set log 0 } } "*" { send_user $expect_match } set spawn_id $login; send $expect_match } } 这个脚本是这样工作的。首先连接到一个login进程和终端。缺省的，所有的对 话都记录到标准输出上(通过send_user)。因为我们对此并不感 兴趣，所以，我们通过命令"log_user 0"来禁止这个功能。(有很多的命令来控制可以看见或者可以记录的东西)。 在循环里面，select等待终端或者login进程上的动作，并且返回一个等待输入 的spawn_id表。如果在表里面找到了一个值的话，case就执行一 个action。比如说，如果字符串"login"出现在login进程的输出中，提示就会被 记录到标准输出上，并且有一个标志被设置以便通知脚本开始 记录用户的击键，直至用户按下了回车键。无论收到什么，都会回显到终端上， 一个相应的action会在脚本的终端那一部分执行。 这些例子显示了expect的作业控制方式。通过把自己插入到对话里面，expect可 以在进程之间创建复杂的I/O流。可以创建多扇出，复用扇入的 ，动态的数据相关的进程图。 相比之下，shell使得它自己一次一行的读取一个文件显的很困难。shell强迫用 户按下控制键(比如，^C,^Z)和关键字(比如fg和bg)来实现作业 的切换。这些都无法从脚本里面利用。相似的是：以非交互方式运行的shell并 不处理“历史记录”和其他一些仅仅为交互式使用设计的特征。这 也出现了和前面哪个passwd程序的相似问题。相似的，也无法编写能够回归的测 试shell的某些动作的shell脚本。结果导致shell的这些方面无 法进行彻底的测试。 如果使用expect的话，可以使用它的交互式的作业控制来驱动shell。一个派生 的shell认为它是在交互的运行着，所以会正常的处理作业控制 。它不仅能够解决检验处理作业控制的shell和其他一些程序的问题。还能够在 必要的时候，让shell代替expect来处理作业。可以支持使用she ll风格的作业控制来支持进程的运行。这意味着：首先派生一个shell，然后把 命令送给shell来启动进程。如果进程被挂起，比如说，发送了 一个^Z，进程就会停下来，并把控制返回给shell。对于expect而言，它还在处 理同一个进程(原来那个shell)。 expect的解决方法不仅具有很大的灵活性，它还避免了重复已经存在于shel l中的作业控制软件。通过使用shell，由于你可以选择你想派 生的shell，所以你可以根据需要获得作业控制权。而且，一旦你需要(比如说检 验的时候)，你就可以驱动一个shell来让这个shell以为它正在 交互式的运行。这一点对于在检测到它们是否在交互式的运行之后会改变输出的 缓冲的程序来说也是很重要的。 为了进一步的控制，在interact执行期间，expect把控制终端(是启动expec t的那个终端，而不是伪终端)设置成生模式以便字符能够正确 的传送给派生的进程。当expect在没有执行interact的时候，终端处于熟模式下 ，这时候作业控制就可以作用于expect本身。 11.[交互式的使用expect] 在前面，我们提到可以通过interact命令来交互式的使用脚本。基本上来说 ，interact命令提供了对对话的自由访问，但我们需要一些更 精细的控制。这一点，我们也可以使用expect来达到，因为expect从标准输入中 读取输入和从进程中读取输入一样的简单。 但是，我们要使用expect_user和send_user来进行标准I/O，同时不改变spawn_i d。 下面的这个脚本在一定的时间内从标准输入里面读取一行。这个脚本叫做ti med_read，可以从csh里面调用，比如说，set answer="timed_read 30"就能调用它。 #!/usr/local/bin/expect -f set timeout [lindex $argv 1] expect_user "* " send_user $expect_match 第三行从用户那里接收任何以新行符结束的任何一行。最后一行把它返回给标准 输出。如果在特定的时间内没有得到任何键入，则返回也为空 。 第一行支持"#!"的系统直接的启动脚本。(如果把脚本的属性加上可执行属性则 不要在脚本前面加上expect)。当然了脚本总是可以显式的用"ex pect scripot"来启动。在-c后面的选项在任何脚本语句执行前就被执行。比如说，不 要修改脚本本身，仅仅在命令行上加上-c "trace..."，该脚本可以加上trace功能了(省略号表示trace的选项)。 在命令行里实际上可以加上多个命令，只要中间以";"分开就可以了。比如说， 下面这个命令行： expect -c "set timeout 20;spawn foo;expect" 一旦你把超时时限设置好而且程序启动之后，expect就开始等待文件结束 符或者20秒的超时时限。 如果遇到了文件结束符(EOF)，该程序就会停下来，然后expect返回。如果是遇 到了超时的情况，expect就返回。在这两中情况里面，都隐式的 杀死了当前进程。 如果我们不使用expect而来实现以上两个例子的功能的话，我们还是可以学习到 很多的东西的。在这两中情况里面，通常的解决方案都是fork 另一个睡眠的子进程并且用signal通知原来的shell。如果这个过程或者读先发 生的话，shell就会杀司那个睡眠的进程。 传递pid和防止后台进程产生启动信息是一个让除了高手级shell程序员之外的人 头痛的事情。提供一个通用的方法来象这样启动多个进程会使s hell脚本非常的复杂。 所以几乎可以肯定的是，程序员一般都用一个专门C程序来解决这样一个问题。 expect_user,send_user,send_error(向标准错误终端输出)在比较长的， 用来把从进程来的复杂交互翻译成简单交互的expect脚本里面 使用的比较频繁。在参考[7]里面，Libs描述怎样用脚本来安全的包裹(wrap)adb ，怎样把系统管理员从需要掌握adb的细节里面解脱出来，同时 大大的降低了由于错误的击键而导致的系统崩溃。 一个简单的例子能够让ftp自动的从一个私人的帐号里面取文件。在这种 情况里，要求提供密码。 即使文件的访问是受限的，你也应该避免把密码以明文的方式存储在文件里面。 把密码作为脚本运行时的参数也是不合适的，因为用ps命令能 看到它们。有一个解决的方法就是在脚本运行的开始调用expect_user来让用户 输入以后可能使用的密码。这个密码必须只能让这个脚本知道， 即使你是每个小时都要重试ftp。 即使信息是立即输入进去的，这个技巧也是非常有用。比如说，你可以写 一个脚本，把你每一个主机上不同的帐号上的密码都改掉，不 管他们使用的是不是同一个密码数据库。如果你要手工达到这样一个功能的话， 你必须Telnet到每一个主机上，并且手工输入新的密码。而使 用expect,你可以只输入密码一次而让脚本来做其它的事情。 expect_user和interact也可以在一个脚本里面混合的使用。考虑一下在 调试一个程序的循环时，经过好多步之后才失败的情况。一个ex pect脚本可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将 控制返回给键盘。它也可以在返回控制之前，在循环体和条件 测试之间来回的切换。 6.[passwd和一致性检查] 在前面，我们提到passwd程序在缺乏用户交互的情况下，不能运行，passwd 会忽略I/O重定向，也不能嵌入到管道里边以便能从别的程序或者文件里读取输 入。这个程序坚持要求真正的与用户进行交互。因为安全的原因，passwd被设计 成这样，但结果导致没有非交互式的方法来检验passwd。这样一个对系统安全 至关重要的程序竟然没有办法进行可靠的检验，真实具有讽刺意味。 passwd以一个用户名作为参数，交互式的提示输入密码。下面的expect脚 本以用户名和密码作为参数而非交互式的运行。 spawn oasswd [lindex $argv 1] set password [lindex $argv 2] expect "*password:" send "$password " expect "*password:" send "$password " expect eof 第一行以用户名做参数启动passwd程序，为方便起见，第二行把密码存到 一个变量里面。和shell类似，变量的使用也不需要提前声明。 在第三行，expect搜索模式"*password:"，其中*允许匹配任意输入，所 以对于避免指定所有细节而言是非常有效的。 上面的程序里没有action,所以 expect检测到该模式后就继续运行。 一旦接收到提示后，下一行就就把密码送给当前进程。表明回车。(实 际上，所有的C的关于字符的约定都支持)。上面的程序中有两个expect-send 序列，因为passwd为了对输入进行确认，要求进行两次输入。在非交互式程序 里面，这是毫无必要的，但由于假定passwd是在和用户进行交互，所以我们的 脚本还是这样做了。 最后，"expect eof"这一行的作用是在passwd的输出中搜索文件结束符， 这一行语句还展示了关键字的匹配。另外一个关键字匹配就是timeout了， timeout被用于表示所有匹配的失败而和一段特定长度的时间相匹配。在这里 eof是非常有必要的，因为passwd被设计成会检查它的所有I/O是否都成功了， 包括第二次输入密码时产生的最后一个新行。 这个脚本已经足够展示passwd命令的基本交互性。另外一个更加完备的例 子回检查别的一些行为。比如说，下面的这个脚本就能检查passwd程序的别的 几个方面。所有的提示都进行了检查。对垃圾输入的检查也进行了适当的处 理。进程死亡，超乎寻常的慢响应，或者别的非预期的行为都进行了处理。 spawn passwd [lindex $argv 1] expect eof {exit 1} timeout {exit 2} "*No such user.*" {exit 3} "*New password:" send "[lindex $argv 2 " expect eof {exit 4} timeout {exit 2} "*Password too long*" {exit 5} "*Password too short*" {exit 5} "*Retype ew password:" send "[lindex $argv 3] " expect timeout {exit 2} "*Mismatch*" {exit 6} "*Password unchanged*" {exit 7} " " expect timeout {exit 2} "*" {exit 6} eof 这个脚本退出时用一个数字来表示所发生的情况。0表示passwd程序正常 运行，1表示非预期的死亡，2表示锁定，等等。使用数字是为了简单起见。 expect返回字符串和返回数字是一样简单的，即使是派生程序自身产生的消息 也是一样的。实际上，典型的做法是把整个交互的过程存到一个文件里面，只 有当程序的运行和预期一样的时候才把这个文件删除。否则这个log被留待以 后进一步的检查。 这个passwd检查脚本被设计成由别的脚本来驱动。这第二个脚本从一个文 件里面读取参数和预期的结果。对于每一个输入参数集，它调用第一个脚本并 且把结果和预期的结果相比较。(因为这个任务是非交互的，一个普通的老式 shell就可以用来解释第二个脚本)。比如说，一个passwd的数据文件很有可能 就象下面一样。 passwd.exp 3 bogus - - passwd.exp 0 fred abledabl abledab l passwd.exp 5 fred abcdefghijklm - passwd.exp 5 fred abc - passwd.exp 6 fred foobar b ar passwd.exp 4 fred ^C - 第一个域的名字是要被运行的回归脚本。第二个域是需要和结果相匹配的 退出值。第三个域就是用户名。第四个域和第五个域就是提示时应该输入的密 码。减号仅仅表示那里有一个域，这个域其实绝对不会用到。在第一个行中 ，bogus表示用户名是非法的，因此passwd会响应说：没有此用户。expect在 退出时会返回3，3恰好就是第二个域。在最后一行中，^C就是被切实的送给程 序来验证程序是否恰当的退出。 通过这种方法，expect可以用来检验和调试交互式软件，这恰恰是IEEE的 POSIX 1003.2(shell和工具)的一致性检验所要求的。进一步的说明请参考 Libes[6]。 7.[rogue 和伪终端] Unix用户肯定对通过管道来和其他进程相联系的方式非常的熟悉(比如说： 一个shell管道)。expect使用伪终端来和派生的进程相联系。伪终端提供了终 端语义以便程序认为他们正在和真正的终端进行I/O操作。 比如说，BSD的探险游戏rogue在生模式下运行，并假定在连接的另一端是 一个可寻址的字符终端。可以用expect编程，使得通过使用用户界面可以玩这 个游戏。 rogue这个探险游戏首先提供给你一个有各种物理属性，比如说力量值，的 角色。在大部分时间里，力量值都是16，但在几乎每20次里面就会有一个力量 值是18。很多的rogue玩家都知道这一点，但没有人愿意启动程序20次以获得一 个好的配置。下面的这个脚本就能达到这个目的。 for {} {1} {} { spawn rogue expect "*Str:18*" break "*Str:16*" close wait } interact 第一行是个for循环，和C语言的控制格式很象。rogue启动后，expect就 检查看力量值是18还是16，如果是16，程序就通过执行close和wait来退出。 这两个命令的作用分别是关闭和伪终端的连接和等待进程退出。rogue读到一 个文件结束符就推出，从而循环继续运行，产生一个新的rogue游戏来检查。 当一个值为18的配置找到后，控制就推出循环并跳到最后一行脚本。 interact把控制转移给用户以便他们能够玩这个特定的游戏。 想象一下这个脚本的运行。你所能真正看到的就是20或者30个初始的配置 在不到一秒钟的时间里掠过屏幕，最后留给你的就是一个有着很好配置的游戏 。唯一比这更好的方法就是使用调试工具来玩游戏。 我们很有必要认识到这样一点：rogue是一个使用光标的图形游戏。 expect程序员必须了解到：光标的运动并不一定以一种直观的方式在屏幕上体 现。幸运的是，在我们这个例子里，这不是一个问题。将来的对expect的改 进可能会包括一个内嵌的能支持字符图形区域的终端模拟器。 8.[ftp] 我们使用expect写第一个脚本并没有打印出"Hello,World"。实际上，它 实现了一些更有用的功能。它能通过非交互的方式来运行ftp。ftp是用来在支 持TCP/IP的网络上进行文件传输的程序。除了一些简单的功能，一般的实现都 要求用户的参与。 下面这个脚本从一个主机上使用匿名ftp取下一个文件来。其中，主机名 是第一个参数。文件名是第二个参数。 spawn ftp [lindex $argv 1] expect "*Name*" send "anonymous " expect "*Password:*" send [exec whoami] expect "*ok*ftp>;*" send "get [lindex $argv 2] " expect "*ftp>;*" 上面这个程序被设计成在后台进行ftp。虽然他们在底层使用和expect类 似的机制，但他们的可编程能力留待改进。因为expect提供了高级语言，你可 以对它进行修改来满足你的特定需求。比如说，你可以加上以下功能： ：坚持－－如果连接或者传输失败，你就可以每分钟或者每小时，甚 至可以根据其他因素，比如说用户的负载，来进行不定期的 重试。 ：通知－－传输时可以通过mail,write或者其他程序来通知你，甚至 可以通知失败。 ：初始化－每一个用户都可以有自己的用高级语言编写的初始化文件 (比如说，.ftprc)。这和C shell对.cshrc的使用很类似。 expect还可以执行其他的更复杂的任务。比如说，他可以使用McGill大学 的Archie系统。Archie是一个匿名的Telnet服务，它提供对描述Internet上可 通过匿名ftp获取的文件的数据库的访问。通过使用这个服务，脚本可以询问 Archie某个特定的文件的位置，并把它从ftp服务器上取下来。这个功能的实 现只要求在上面那个脚本中加上几行就可以。 现在还没有什么已知的后台-ftp能够实现上面的几项功能，能不要说所有 的功能了。在expect里面，它的实现却是非常的简单。“坚持”的实现只要求 在expect脚本里面加上一个循环。“通知”的实现只要执行mail和write就可以 了。“初始化文件”的实现可以使用一个命令，source .ftprc，就可以了， 在.ftprc里面可以有任何的expect命令。 虽然这些特征可以通过在已有的程序里面加上钩子函数就可以，但这也不 能保证每一个人的要求都能得到满足。唯一能够提供保证的方法就是提供一种 通用的语言。一个很好的解决方法就是把Tcl自身融入到ftp和其他的程序中间 去。实际上，这本来就是Tcl的初衷。在还没有这样做之前，expect提供了一 个能实现大部分功能但又不需要任何重写的方案。 9.[fsck] fsck是另外一个缺乏足够的用户接口的例子。fsck几乎没有提供什么方法 来预先的回答一些问题。你能做的就是给所有的问题都回答"yes"或者都回答 "no"。 下面的程序段展示了一个脚本如何的使的自动的对某些问题回答"yes"， 而对某些问题回答"no"。下面的这个脚本一开始先派生fsck进程，然后对其 中两种类型的问题回答"yes"，而对其他的问题回答"no"。 for {} {1} {} { expect eof break "*UNREF FILE*CLEAR?" {send "r "} "*BAD INODE*FIX?" {send "y "} "*?" {send "n "} } 在下面这个版本里面，两个问题的回答是不同的。而且，如果脚本遇到 了什么它不能理解的东西，就会执行interact命令把控制交给用户。用户的 击键直接交给fsck处理。当执行完后，用户可以通过按"+"键来退出或者把 控制交还给expect。如果控制是交还给脚本了，脚本就会自动的控制进程的 剩余部分的运行。 for {} {1} {}{ expect eof break "*UNREF FILE*CLEAR?" {send "y "} "*BAD INODE*FIX?" {send "y "} "*?" {interact +} } 如果没有expect，fsck只有在牺牲一定功能的情况下才可以非交互式的 运行。fsck几乎是不可编程的，但它却是系统管理的最重要的工具。许多别 的工具的用户接口也一样的不足。实际上，正是其中的一些程序的不足导致 了expect的诞生。 10.[控制多个进程：作业控制] expect的作业控制概念精巧的避免了通常的实现困难。其中包括了两个问 题：一个是expect如何处理经典的作业控制，即当你在终端上按下^Z键时 expect如何处理；另外一个就是expect是如何处理多进程的。 对第一个问题的处理是：忽略它。expect对经典的作业控制一无所知。比 如说，你派生了一个程序并且发送一个^Z给它，它就会停下来(这是伪终端的 完美之处)而expect就会永远的等下去。 但是，实际上，这根本就不成一个问题。对于一个expect脚本，没有必要 向进程发送^Z。也就是说，没有必要停下一个进程来。expect仅仅是忽略了 一个进程，而把自己的注意力转移到其他的地方。这就是expect的作业控制 思想，这个思想也一直工作的很好。 从用户的角度来看是象这样的：当一个进程通过spawn命令启动时，变量 spawn_id就被设置成某进程的描述符。由spawn_id描述的进程就被认为是当 前进程。(这个描述符恰恰就是伪终端文件的描述符，虽然用户把它当作一个 不透明的物体)。expect和send命令仅仅和当前进程进行交互。所以，切换一 个作业所需要做的仅仅是把该进程的描述符赋给spawn_id。 这儿有一个例子向我们展示了如何通过作业控制来使两个chess进程进行 交互。在派生完两个进程之后，一个进程被通知先动一步。在下面的循环里 面，每一步动作都送给另外一个进程。其中，read_move和write_move两个过 程留给读者来实现。(实际上，它们的实现非常的容易，但是，由于太长了所 以没有包含在这里)。 spawn chess ;# start player one set id1 $spawn_id expect "Chess " send "first " ;# force it to go first read_move spawn chess ;# start player two set id2 $spawn_id expect "Chess " for {} {1} {}{ send_move read_move set spawn_id $id1 send_move read_move set spawn_id $id2 } 有一些应用程序和chess程序不太一样，在chess程序里，的两个玩家 轮流动。下面这个脚本实现了一个冒充程序。它能够控制一个终端以便用户 能够登录和正常的工作。但是，一旦系统提示输入密码或者输入用户名的时 候，expect就开始把击键记下来，一直到用户按下回车键。这有效的收集了 用户的密码和用户名，还避免了普通的冒充程序的"Incorrect password-try again"。而且，如果用户连接到另外一个主机上，那些额外的登录也会被 记录下来。 spawn tip /dev/tty17 ;# open connection to set tty $spawn_id ;# tty to be spoofed spawn login set login $spawn_id log_user 0 for {} {1} {} { set ready [select $tty $login] case $login in $ready { set spawn_id $login expect {"*password*" "*login*"}{ send_user $expect_match set log 1 } "*" ;# ignore everything else set spawn_id $tty; send $expect_match } case $tty in $ready { set spawn_id $tty expect "* *"{ if $log { send_user $expect_match set log 0 } } "*" { send_user $expect_match } set spawn_id $login; send $expect_match } } 这个脚本是这样工作的。首先连接到一个login进程和终端。缺省的， 所有的对话都记录到标准输出上(通过send_user)。因为我们对此并不感兴趣， 所以，我们通过命令"log_user 0"来禁止这个功能。(有很多的命令来控制 可以看见或者可以记录的东西)。 在循环里面，select等待终端或者login进程上的动作，并且返回一个 等待输入的spawn_id表。如果在表里面找到了一个值的话，case就执行一个 action。比如说，如果字符串"login"出现在login进程的输出中，提示就会 被记录到标准输出上，并且有一个标志被设置以便通知脚本开始记录用户的 击键，直至用户按下了回车键。无论收到什么，都会回显到终端上，一个相 应的action会在脚本的终端那一部分执行。 这些例子显示了expect的作业控制方式。通过把自己插入到对话里面， expect可以在进程之间创建复杂的I/O流。可以创建多扇出，复用扇入的， 动态的数据相关的进程图。 相比之下，shell使得它自己一次一行的读取一个文件显的很困难。 shell强迫用户按下控制键(比如，^C,^Z)和关键字(比如fg和bg)来实现作业的 切换。这些都无法从脚本里面利用。相似的是：以非交互方式运行的shell并 不处理“历史记录”和其他一些仅仅为交互式使用设计的特征。这也出现了和 前面哪个passwd程序的相似问题。相似的，也无法编写能够回归的测试shell 的某些动作的shell脚本。结果导致shell的这些方面无法进行彻底的测试。 如果使用expect的话，可以使用它的交互式的作业控制来驱动shell。一 个派生的shell认为它是在交互的运行着，所以会正常的处理作业控制。它不 仅能够解决检验处理作业控制的shell和其他一些程序的问题。还能够在必要 的时候，让shell代替expect来处理作业。可以支持使用shell风格的作业控 制来支持进程的运行。这意味着：首先派生一个shell，然后把命令送给shell 来启动进程。如果进程被挂起，比如说，发送了一个^Z，进程就会停下来，并 把控制返回给shell。对于expect而言，它还在处理同一个进程(原来那个 shell)。 expect的解决方法不仅具有很大的灵活性，它还避免了重复已经存在于 shell中的作业控制软件。通过使用shell，由于你可以选择你想派生的shell， 所以你可以根据需要获得作业控制权。而且，一旦你需要(比如说检验的时 候)，你就可以驱动一个shell来让这个shell以为它正在交互式的运行。这一 点对于在检测到它们是否在交互式的运行之后会改变输出的缓冲的程序来说也 是很重要的。 为了进一步的控制，在interact执行期间，expect把控制终端(是启动 expect的那个终端，而不是伪终端)设置成生模式以便字符能够正确的传送给 派生的进程。当expect在没有执行interact的时候，终端处于熟模式下，这时 候作业控制就可以作用于expect本身。 11.[交互式的使用expect] 在前面，我们提到可以通过interact命令来交互式的使用脚本。基本上 来说，interact命令提供了对对话的自由访问，但我们需要一些更精细的控 制。这一点，我们也可以使用expect来达到，因为expect从标准输入中读取 输入和从进程中读取输入一样的简单。 但是，我们要使用expect_user和 send_user来进行标准I/O，同时不改变spawn_id。 下面的这个脚本在一定的时间内从标准输入里面读取一行。这个脚本叫 做timed_read，可以从csh里面调用，比如说，set answer="timed_read 30" 就能调用它。 #!/usr/local/bin/expect -f set timeout [lindex $argv 1] expect_user "* " send_user $expect_match 第三行从用户那里接收任何以新行符结束的任何一行。最后一行把它 返回给标准输出。如果在特定的时间内没有得到任何键入，则返回也为空。 第一行支持"#!"的系统直接的启动脚本。(如果把脚本的属性加上可执 行属性则不要在脚本前面加上expect)。当然了脚本总是可以显式的用 "expect scripot"来启动。在-c后面的选项在任何脚本语句执行前就被执行。 比如说，不要修改脚本本身，仅仅在命令行上加上-c "trace..."，该脚本可 以加上trace功能了(省略号表示trace的选项)。 在命令行里实际上可以加上多个命令，只要中间以";"分开就可以了。 比如说，下面这个命令行： expect -c "set timeout 20;spawn foo;expect" 一旦你把超时时限设置好而且程序启动之后，expect就开始等待文件 结束符或者20秒的超时时限。 如果遇到了文件结束符(EOF)，该程序就会停 下来，然后expect返回。如果是遇到了超时的情况，expect就返回。在这两 中情况里面，都隐式的杀死了当前进程。 如果我们不使用expect而来实现以上两个例子的功能的话，我们还是可 以学习到很多的东西的。在这两中情况里面，通常的解决方案都是fork另一个 睡眠的子进程并且用signal通知原来的shell。如果这个过程或者读先发生的 话，shell就会杀司那个睡眠的进程。 传递pid和防止后台进程产生启动信息 是一个让除了高手级shell程序员之外的人头痛的事情。提供一个通用的方法 来象这样启动多个进程会使shell脚本非常的复杂。 所以几乎可以肯定的是， 程序员一般都用一个专门C程序来解决这样一个问题。 expect_user,send_user,send_error(向标准错误终端输出)在比较长 的，用来把从进程来的复杂交互翻译成简单交互的expect脚本里面使用的比较 频繁。在参考[7]里面，Libs描述怎样用脚本来安全的包裹(wrap)adb，怎样 把系统管理员从需要掌握adb的细节里面解脱出来，同时大大的降低了由于错 误的击键而导致的系统崩溃。 一个简单的例子能够让ftp自动的从一个私人的帐号里面取文件。在这 种情况里，要求提供密码。 即使文件的访问是受限的，你也应该避免把密码 以明文的方式存储在文件里面。把密码作为脚本运行时的参数也是不合适的， 因为用ps命令能看到它们。有一个解决的方法就是在脚本运行的开始调用 expect_user来让用户输入以后可能使用的密码。这个密码必须只能让这个脚 本知道，即使你是每个小时都要重试ftp。 即使信息是立即输入进去的，这个技巧也是非常有用。比如说，你可 以写一个脚本，把你每一个主机上不同的帐号上的密码都改掉，不管他们使用 的是不是同一个密码数据库。如果你要手工达到这样一个功能的话，你必须 Telnet到每一个主机上，并且手工输入新的密码。而使用expect,你可以只输 入密码一次而让脚本来做其它的事情。 expect_user和interact也可以在一个脚本里面混合的使用。考虑一下 在调试一个程序的循环时，经过好多步之后才失败的情况。一个expect脚本 可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将控制 返回给键盘。它也可以在返回控制之前，在循环体和条件测试之间来回的切 换。 文件ftp-down CODE:[Copy to clipboard]#!/usr/bin/expect -f set ipaddress [lindex $argv 0] set username [lindex $argv 1] set password [lindex $argv 2] spawn ftp $ipaddress expect "*Name*" send "$username " expect "*Password:*" send "$password " expect "* (责任编辑：IT) |