Expect 教程

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]
　　　　expect 　　　　eof　　　　　　　　　　　　{exit 1} 　　　　
　　　　　　　　timeout　　　　　　　　　　　　{exit 2}　　　　
　　　　　　　　"*No such user.*"　　　　{exit 3}　　　　
　　　　　　　　"*New password:"　　　　
　　　　send　"[index $argv 2 "
　　　　expect 　　　　eof　　　　　　　　　　　　{exit 4}　　　　
　　　　　　　　timeout　　　　　　　　　　　　{exit 2}　　　　
　　　　　　　　"*Password too long*"　　　　{exit 5}　　　　
　　　　　　　　"*Password too short*"　　　　{exit 5}　　　　
　　　　　　　　"*Retype ew password:"
　　　　send "[index $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　　　　abledabl
　　　　passwd.exp　　　　5　　　　fred　　　　abcdefghijklm　　　　-
　　　　passwd.exp　　　　5　　　　fred　　　　abc　　　　　　　　-
　　　　passwd.exp　　　　6　　　　fred　　　　foobar　　　　　　　　bar　　　　
　　　　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 {} {} {
　　　　　　　　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　　　　[index $argv 1]
　　　　　　　　expect　"*Name*"
　　　　　　　　send　　　　　"anonymous "
　　　　　　　　expect　"*Password:*"
　　　　　　　　send [exec whoami]
　　　　　　　　expect "*ok*ftp>*"
　　　　　　　　send "get [index $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 {} {} {
　　　　　　　　expect
　　　　　　　　　　　　eof　　　　　　　　break　　　　　　　　
　　　　　　　　　　　　"*UNREF FILE*CLEAR?"　　　　{send "r "}　　　　
　　　　　　　　　　　　"*BAD INODE*FIX?"　　　　{send "y "}　　　　
　　　　　　　　　　　　"*?"　　　　　　　　　　　　{send "n "}　　　　
　　　　}

　　在下面这个版本里面，两个问题的回答是不同的。而且，如果脚本遇见了什么他不能理解的东西，就会执行interact命令把控制交给用户。用户的击键直接交给fsck处理。当执行完后，用户能通过按"+"键来退出或把控制交还给expect。如果控制是交还给脚本了，脚本就会自动的控制进程的剩余部分的运行。

　　　　for {} {}{
　　　　　　　　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 {} {}{
　　　　　　　　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 {} {} {
　　　　　　　　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 [index $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脚本能驱动哪个调试器，设置好断点，执行该程式循环的若干步，然后将控制返回给键盘。他也能在返回控制之前，在循环体和条件测试之间来回的转换。