_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脚本可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将控制返回给键盘。它也可以在返回控制之前，在循环体和条件测试之间来回的切换。
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 {} {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个初始的配置
在不到一秒钟的时间里掠过屏幕，最后留给你的就是一个有着很好配置的上一页 [1] [2] [3] [4] [5] 下一页 |
