Expect 教程(二）

　　Expect语言是基于Tcl的。Tcl实际上是一个子程序库，这些子程序库可以嵌入到程序里从而提供语言服务。　最终的语言有点象一个典型的Shell语言。里面有给变量赋值的set命令，控制程序执行的if,for,continue等命令，还能进行普通的数学和字符串操作。当然了，还可以用exec来调用Unix程序。所有这些功能，Tcl都有。Tcl在参考书籍 Outerhour[3][4]里有详细的描述。

　　Expect是在Tcl基础上创建起来的，它还提供了一些Tcl所没有的命令。spawn命令激活一个Unix程序来进行交互式的运行。　send命令向进程发送字符串。expect命令等待进程的某些字符串。　expect支持正规表达式并能同时等待多个字符串，并对每一个字符串执行不同的操作。expect还能理解一些特殊情况，如超时和遇到文件尾。

　　expect命令和Tcl的case命令的风格很相似。都是用一个字符串去匹配多个字符串。(只要有可能，新的命令总是和已有的Tcl命令相似，以使得该语言保持工具族的继承性)。下面关于expect的定义是从手册[5]上摘录下来的。

 expect　patlist1 action1 patlist2 action2..... 

　　该命令一直等到当前进程的输出和以上的某一个模式相匹配，或者等到时间超过一个特定的时间长度，或者等到遇到了文件的结束为止。

　　如果最后一个action是空的，就可以省略它。

　　每一个patlist都由一个模式或者模式的表(lists)组成。如果有一个模式匹配成功，相应的action就被执行。执行的结果从expect返回。

　　被精确匹配的字符串(或者当超时发生时，已经读取但未进行匹配的字符串)被存贮在变量expect_match里面。如果patlist是eof或者timeout,则发生文件结束或者超时时才执行相应的action.一般超时的时值是10秒，但可以用类似"set timeout 30"之类的命令把超时时值设定为30秒。

　　下面的一个程序段是从一个有关登录的脚本里面摘取的。abort是在脚本的别处定义的过程，而其他的action使用类似与C语言的Tcl原语。

 expect "*welcome*"break "*busy*"{print busy;continue} "*failed*"abort timeoutabort 

　　模式是通常的C Shell风格的正规表达式。模式必须匹配当前进程的从上一个expect或者interact开始的所有输出(所以统配符*使用的非常)的普遍。但是，一旦输出超过2000个字节，前面的字符就会被忘记，这可以通过设定match_max的值来改变。

　　expect命令确实体现了expect语言的最好和最坏的性质。特别是，expect命令的灵活性是以经常出现令人迷惑的语法做代价。除了关键字模式(比如说eof,timeout)那些模式表可以包括多个模式。这保证提供了一种方法来区分他们。但是分开这些表需要额外的扫描，如果没有恰当的用["]括起来，这有可能会把和当成空白字符。由于Tcl提供了两种字符串引用的方法：单引和双引，情况变的更糟。(在Tcl里面，如果不会出现二义性话，没有必要使用引号)。在expect的手册里面，还有一个独立的部分来解释这种复杂性。幸运的是：有一些很好的例子似乎阻止了这种抱怨。但是，这个复杂性很有可能在将来的版本中再度出现。为了增强可读性，在本文中，提供的脚本都假定双引号是足够的。

　　字符可以使用反斜杠来单独的引用，反斜杠也被用于对语句的延续，如果不加反斜杠的话，语句到一行的结尾处就结束了。这和Tcl也是一致的。Tcl在发现有开的单引号或者开的双引号时都会继续扫描。而且，分号可以用于在一行中分割多个语句。这乍听起来有点让人困惑，但是，这是解释性语言的风格，但是，这确实是Tcl的不太漂亮的部分。

　　5.[callback]

　　令人非常惊讶的是，一些小的脚本如何的产生一些有用的功能。下面是一个拨电话号码的脚本。他用来把收费反向，以便使得长途电话对计算机计费。这个脚本用类似“expect callback.exp 12016442332”来激活。其中，脚本的名字便是callback.exp，而+1(201)644-2332是要拨的电话号码。

 #first give the user some time to logout exec sleep 4 spawn tip modem expect "*connected*" send "ATD [index $argv 1] " #modem takes a while to connect set timeout 60 expect "*CONNECT*" 

　　第一行是注释，第二行展示了如何调用没有交互的Unix程序。sleep 4会使程序阻塞4秒，以使得用户有时间来退出，因为modem总是会回叫用户已经使用的电话号码。

　　下面一行使用spawn命令来激活tip程序，以便使得tip的输出能够被expect所读取，使得tip能从send读输入。一旦tip说它已经连接上，modem就会要求去拨打大哥电话号码。(假定modem都是贺氏兼容的，但是本脚本可以很容易的修改成能适应别的类型的modem)。不论发生了什么，expect都会终止。如果呼叫失败，expect脚本可以设计成进行重试，但这里没有。如果呼叫成功，getty会在expect退出后检测到DTR，并且向用户提示loging:。(实用的脚本往往提供更多的错误检测)。

　　这个脚本展示了命令行参数的使用，命令行参数存贮在一个叫做argv的表里面(这和C语言的风格很象)。在这种情况下，第一个元素就是电话号码。方括号使得被括起来的部分当作命令来执行，结果就替换被括起来的部分。这也和C Shell的风格很象。

　　这个脚本和一个大约60K的C语言程序实现的功能相似。

　　6.[passwd和一致性检查]

　　在前面，我们提到passwd程序在缺乏用户交互的情况下，不能运行，passwd会忽略I/O重定向，也不能嵌入到管道里边以便能从别的程序或者文件里读取输入。这个程序坚持要求真正的与用户进行交互。因为安全的原因，passwd被设计成这样，但结果导致没有非交互式的方法来检验passwd。这样一个对系统安全至关重要的程序竟然没有办法进行可靠的检验，真实具有讽刺意味。

　　passwd以一个用户名作为参数，交互式的提示输入密码。下面的expect脚本以用户名和密码作为参数而非交互式的运行。

 spawn oasswd [index $argv 1] set password [index $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 [index $argv 1] expecteof{exit 1} timeout{exit 2} "*No such user.*"{exit 3} "*New password:" send　"[index $argv 2 " expecteof{exit 4} timeout{exit 2} "*Password too long*"{exit 5} "*Password too short*"{exit 5} "*Retype ew password:" send "[index $argv 3] " expecttimeout{exit 2} "*Mismatch*"{exit 6} "*Password unchanged*"{exit 7} " " expecttimeout{exit 2} "*"{exit 6} eof 

　　这个脚本退出时用一个数字来表示所发生的情况。0表示passwd程序正常运行，1表示非预期的死亡，2表示锁定，等等。使用数字是为了简单起见。expect返回字符串和返回数字是一样简单的，即使是派生程序自身产生的消息也是一样的。实际上，典型的做法是把整个交互的过程存到一个文件里面，只有当程序的运行和预期一样的时候才把这个文件删除。否则这个log被留待以后进一步的检查。

　　这个passwd检查脚本被设计成由别的脚本来驱动。这第二个脚本从一个文件里面读取参数和预期的结果。对于每一个输入参数集，它调用第一个脚本并且把结果和预期的结果相比较。(因为这个任务是非交互的，一个普通的老式shell就可以用来解释第二个脚本)。比如说，一个passwd的数据文件很有可能就象下面一样。

 passwd.exp3bogus-- passwd.exp0fredabledablabledabl passwd.exp5fredabcdefghijklm- passwd.exp5fredabc- passwd.exp6fredfoobarbar passwd.exp4fred^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的改进可能会包括一个内嵌的能支持字符图形区域的终端模拟器。