Expect 教程中文版
本教程由*葫芦娃*翻译，并做了适当的修改，可以自由的用于非商业目的。
[BUG]
有不少部分，翻译的时候不能作到“信，达”。当然了，任何时候都没有做到“雅”，希望各位谅解。
[原著]
Don Libes: National Institute of Standards and Technology
libes@cme.nist.gov
[目录]
1.摘要
2.关键字
3.简介
4.Expect综述
5.callback
6.passwd 和一致性检查
7.rogue 和伪终端
8.ftp
9.fsck
10.多进程控制：作业控制
11.交互式使用Expect
12.交互式Expect编程
13.非交互式程序的控制
14.Expect的速度
15.安全方面的考虑
16.Expect资源
17.参考书籍
1.[摘要]
现代的Shell对程序提供了最小限度的控制(开始，停止，等等)，而把交互的特性留给了用户。 这意味着有些程序，你不能非交互的运行，比如说passwd。 有一些程序可以非交互的运行，但在很大程度上丧失了灵活性，比如说fsck。这表明Unix的工具构造逻辑开始出现问题。Expect恰恰填补了其中的一 些裂痕，解决了在Unix环境中长期存在着的一些问题。
Expect使用Tcl作为语言核心。不仅如此，不管程序是交互和还是非交互的，Expect都能运用。这是一个小语言和Unix的其他工具配合起来产生强大功能的经典例子。
本部分教程并不是有关Expect的实现，而是关于Expect语言本身的使用，这主要也是通过不同的脚本描述例子来体现。其中的几个例子还例证了Expect的几个新特征。
2.[关键字]
Expect,交互，POSIX,程序化的对话，Shell,Tcl,Unix;
3.[简介]
一个叫做fsck的Unix文件系统检查程序，可以从Shell里面用-y或者-n选项来执行。 在手册[1]里面，-y选项的定义是象这样的。
“对于fsck的所有问题都假定一个“yes”响应；在这样使用的时候，必须特别的小心，因为它实际上允许程序无条件的继续运行，即使是遇到了一些非常严重的错误”
相比之下，-n选项就安全的多，但它实际上几乎一点用都没有。这种接口非常的糟糕，但是却有许多的程序都是这种风格。 文件传输程序ftp有一个选项可以禁止交互式的提问，以便能从一个脚本里面运行。但一旦发生了错误，它没有提供的处理措施。
Expect是一个控制交互式程序的工具。他解决了fsck的问题，用非交互的方式实现了所有交互式的功能。Expect不是特别为fsck设计的，它也能进行类似ftp的出错处理。
fsck和ftp的问题向我们展示了象sh,csh和别的一些shell提供的用户接口的局限性。 Shell没有提供从一个程序读和象一个程序写的 功能。这意味着shell可以运行fsck但只能以牺牲一部分fsck的灵活性做代价。有一些程序根本就不能被执行。比如说，如果没有一个用户接口交互式 的提供输入，就没法运行下去。其他还有象Telnet,crypt,su,rlogin等程序无法在shell脚本里面自动执行。还有很多其他的应用程序 在设计是也是要求用户输入的。
Expect被设计成专门针和交互式程序的交互。一个Expect程序员可以写一个脚本来描述程序和用户的对话。接着Expect程序可以非交互的运 行“交互式”的程序。写交互式程序的脚本和写非交互式程序的脚本一样简单。Expect还可以用于对对话的一部分进行自动化，因为程序的控制可以在键盘和 脚本之间进行切换。
bes[2]里面有详细的描述。简单的说，脚本是用一种解释性语言写的。(也有C和C++的Expect库可供使用，但这超出了本文的范围).Expect提供了创建交互式进程和读写它们的输入和输出的命令。 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
timeout abort
模式是通常的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]
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个初始的配置在不到一秒钟的时间里掠过屏幕，最后留给你的就是一个有着很好配置的游戏。唯一比这更好的方法就是使用调试工具来玩游戏。
我们很有必要认识到这样一点：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 {} {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-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来处理作业。可以支持使用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脚本可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将控制返回给键盘。它也可以在返回控制之前，在循环体和条件测试之间来回 的切换.
=====================================================
[From] http://www.linuxeden.com/edu/doctext.php?docid=2288
我们通过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作为用户名；然后等待Password:提示符，并发出响应sillyme。
Login: somebody Password: sillyme
这个脚本用来实现一个登录过程，并用特定的用户名和密码实现登录。
Expect最简单的脚本操作模式本质上和Chat脚本工作模式是一样的。下面我们分析一个响应chsh命令的脚本。我们首先回顾一下这个交互命令的格式。假设我们为用户chavez改变登录脚本，命令交互过程如下：
# 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。
下面是一个能用来实现自动执行该命令的Expect脚本：
#!/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命令来启动脚本和命令的会话，这里启动的是chsh命令，实际上命令是以衍生子进程的方式来运行的。
随后的expect和send命令用来实现交互过程。脚本首先等待输出中出现]:字符串，一旦在输出中出现chsh输出到的特征字符串(一般特征字符串往 往是等待输入的最后的提示符的特征信息)。对于其他不匹配的信息则会完全忽略。当脚本得到特征字符串时，expect将发送/bin/tcsh和一个回车 符给chsh命令。最后脚本等待命令退出(chsh结束)，一旦接收到标识子进程已经结束的eof字符，expect脚本也就退出结束。
决定如何响应
管理员往往有这样的需求，希望根据当前的具体情况来以不同的方式对一个命令进行响应。我们可以通过后面的例子看到expect可以实现非常复杂的条件响应，而仅仅通过简单的修改预处理脚本就可以实现。下面的例子是一个更复杂的expect-send例子：
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包含有整个匹配输出)。()可能会出现嵌套情况，这这种情况下编码从最内层到最外层来进行的。
使用超时
下一个expect例子中将阐述具有超时功能的提示符函数。这个脚本提示用户输入，如果在给定的时间内没有输入，则会超时并返回一个默认的响应。这个脚本接收三个参数：提示符字串，默认响应和超时时间(秒)。
#!/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]
脚本的第一部分首先是得到运行参数并将其保存到内部变量中。
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命令将response变量的值加上回车符发送给标准输出。
一个有趣的事情是该脚本没有使用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"
一个更复杂的例子
下面我们将讨论一个更加复杂的expect脚本例子，这个脚本使用了一些更复杂的控制结构和很多复杂的交互过程。这个例子用来实现发送write命令给任意的用户，发送的消息来自于一个文件或者来自于键盘输入。
#!/usr/bin/expect
# Write to multiple users from a prepared file
# or a message input interactively
if {$argc<2} {
send_user "usage: $argv0 file user1 user2 ... "
exit
}
send_user命令用来显示使用帮助信息到父进程(一般为用户的shell)的标准输出。
set nofile 0
# get filename via the Tcl lindex function
set file [lindex $argv 0]
if {$file=="i"} {
set nofile 1
} else {
# make sure message file exists
if {[file isfile $file]!=1} {
send_user "$argv0: file $file not found. "
exit }}
这部分实现处理脚本启动参数，其必须是一个储存要发送的消息的文件名或表示使用交互输入得到发送消的内容的"i"命令。
变量file被设置为脚本的第一个参数的值，是通过一个Tcl函数lindex来实现的，该函数从列表/数组得到一个特定的元素。[]用来实现将函数lindex的返回值作为set命令的参数。
如果脚本的第一个参数是小写的"i"，那么变量nofile被设置为1，否则通过调用Tcl的函数isfile来验证参数指定的文件存在，如果不存在就报错退出。
可以看到这里使用了if命令来实现逻辑判断功能。该命令后面直接跟判断条件，并且执行在判断条件后的{}内的命令。if条件为false时则运行else后的程序块。
set procs {}
# start write processes
for {set i 1} {$i<$argc}
{incr i} {
spawn -noecho write
[lindex $argv $i]
lappend procs $spawn_id
}
最后一部分使用spawn命令来启动write进程实现向用户发送消息。这里使用了for命令来实现循环控制功能，循环变量首先设置为1，然后因此递增。 循环体是最后的{}的内容。这里我们是用脚本的第二个和随后的参数来spawn一个write命令，并将每个参数作为发送消息的用户名。lappend命 令使用保存每个spawn的进程的进程ID号的内部变量$spawn_id在变量procs中构造了一个进程ID号列表。
if {$nofile==0} {
setmesg [open "$file" "r"]
} else {
send_user "enter message,
ending with ^D: " }
最后脚本根据变量nofile的值实现打开消息文件或者提示用户输入要发送的消息。
set timeout -1
while 1 {
if {$nofile==0} {
if {[gets $mesg chars] == -1} break
set line "$chars "
} else {
expect_user {
-re " " {}
eof break }
set line $expect_out(buffer) }
foreach spawn_id $procs {
send $line }
sleep 1}
exit
上面这段代码说明了实际的消息文本是如何通过无限循环while被发送的。while循环中的 if判断消息是如何得到的。在非交互模式下，下一行内容从消息文件中读出，当文件内容结束时while循环也就结束了。(break命令实现终止循环) 。
在交互模式下，expect_user命令从用户接收消息，当用户输入ctrl+D时结束输入，循环同时结束。 两种情况下变量$line都被用来保存下一行消息内容。当是消息文件时，回车会被附加到消息的尾部。
foreach循环遍历spawn的所有进程，这些进程的ID号都保存在列表变量$procs中，实现分别和各个进程通信。send命令组成了 foreach的循环体，发送一行消息到当前的write进程。while循环的最后是一个sleep命令，主要是用于处理非交互模式情况下，以确保消息 不会太快的发送给各个write进程。当while循环退出时，expect脚本结束。
参考资源
Expect软件版本深带有很多例子脚本，不但可以用于学习和理解expect脚本，而且是非常使用的工具。一般可以在 /usr/doc/packages/expect/example看到它们，在某些linux发布中有些expect脚本保存在/usr/bin目录 下。
Don Libes, Exploring Expect, O'Reilly & Associates, 1995.
John Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, 1994.
一些有用的expect脚本
autoexpect:这个脚本将根据自身在运行时用户的操作而生成一个expect脚本。它的功能某种程度上类似于在Emacs编辑器的键盘宏工具。一个自动创建的脚本可能是创建自己定制脚本的好的开始。
kibitz:这是一个非常有用的工具。通过它两个或更多的用户可以连接到同一个shell进程。可以用于技术支持或者培训（参见下图）。
同样可以用于其他一些要求同步的协同任务。例如我希望和另外一个同事一起编辑一封信件，这样通过kibitz我们可以共享同一个运行编辑器的脚本，同时进行编辑和查看信件内容。
tkpasswd: 这个脚本提供了修改用户密码的GUI工具，包括可以检查密码是否是基于字典模式。这个工具同时是一个学习expect和tk的好实例。
==================================================
Expect 超出预期
[From] http://www-128.ibm.com/developerworks/cn/linux/server/clinic/part1/index.html
Cameron Laird 用一篇对受欢迎的 Expect 工具的概述开启了他新的月度专栏，Expect 是一种功能大大超出大多数程序员和管理员认识的语言。Expect 非常适合保持服务器正常运转所需的通用工作，实际上，它可以作为一种（几乎）通用的编程语言。通过单击本文顶部或底部的 讨论在 论坛中将您对本文的想法与作者和其他读者一起分享。
您是一名“系统程序员”― 您编写代码以保持服务器正常运转，并且为您的应用程序开发人员同事提供所需的底层功能。您从哪里获取所需的信息呢？大多数编程参考大全关心客户机或者“应用程序”问题，而管理书籍通常回避编程而致力于“配置”。
我希望您会发现这一新的“服务器诊所”专栏是有用的来源之一。每个月，我都将解决在服务器的“维护与支持”中遇到的一个编程问题或一类共同问题。
专 栏第一部分将 Expect 作为您最应该了解的一种语言进行介绍。您可能已经熟悉 Expect 了。不过，您也可能从未见过 Expect 所管理任务的完整范围。Expect 实现了一种 Linux 系统编程的通用性，其它语言 ― 即使是 C、Java 或 bash ― 都无法与之相比。虽然未来的专栏文章将展示使用各种语言的解决方案，但 Expect 很可能是出现频率最高的一个。
什么使 Expect“通用”呢？首先，应了解 Expect 是 Tcl/Tk 编程语言的适当超集。Tcl 是在各种程序中使用的一种高级语言。 它过去通常与 Perl、Python、Ruby 和其它语言一起被归为“脚本编制”语言。在 2002 年，最明智的做法是抛开某些历史事件，简单地将所有这些语言视为高效率的开放源码语言。Tcl 在计算机辅助设计（CAD）领域中特别流行，象 Cisco 和 Nortel 这样的联网设备供应商也都使用它。与其它“脚本编制”语言一样，Tcl 的内置功能适用于文本处理、数据库管理、联网和算法等领域中的最常见问题。
Tcl 是 Expect 的基础。任何 Tcl 程序都自动是 Expect 程序。因为有下面两个原因，所以强调这一点很重要：
- 许多人只知道 Expect 是一种“工具”，而从不了解它是一种完全成熟的编程语言。
- 1994 年，许多真正认识到 Expect 的通用能力的程序员都被它迷住了。
Expect 的作者是（美国）国家标准与技术协会（National Institute of Standards and Technology）的 Don Libes。他在 1994 年出版了一本关于 Expect 的出色书籍。该书现在仍只有第一版，它没有竞争者；这本书写得太好了，以至于没有出版商出版另一本书。最引人注目的是， Exploring Expect（请参阅本文后面的 参考资料）一直不需要更新。它的清晰和精确很好地经受了时间的考验。
这里的问题是，过去八年以来，Expect 的底层 Tcl 基础已经有了极大发展。最初编写 Expect 时，Tcl 并不追求成为通用的编程语言。从那时起，Tcl 已经：
- 知道如何处理完整的八位数据，甚至能方便地处理 Unicode；
- 添加了方便的 TCP/IP 抽象；
- 获取了数据和时间计算以及格式化方面的能力；
- 改进并合理化了其字符串处理；
因此，请记住：如果 Perl、Java 或 C 可以解决一个问题，那么 Tcl 以及 Expect 很可能也可以解决。
Tcl 有一项任何其它编程语言都“无与伦比（out of the box）”的工作，这就是图形用户界面（GUI）的构建。虽然从 ActiveState Tools Corporation 下载的 Linux 版标准 ActiveTcl 二进制分发版只有大约 10 兆字节，但它不仅包含 Expect，而且还包含功能齐全的集成 GUI 工具箱。下面的示例将说明这个名为“Tk”的工具箱如何简洁地表达 GUI 解决方案。
  |
|
Expect 的 Tcl/Tk 基础适用于范围非常广的编程。请记住，Expect 可以完成 Tcl/Tk 所能做的一切。除此之外，Expect 添加了三大类别的附加功能：
- 扩展的调试选项
- 描述面向字符对话框的便利命令
- 棘手的面向字符终端的独一无二的管理
这些功能中第一个是常规的。Expect 有各种“开关”来记录或报告其操作的各个方面。
Expect 的用途是使面向字符的交互自动化。您可能已经自己完成了许多这种工作。每次编写命令行管道或重定向输入／输出（I/O）流时，您都在让计算机管理这些工作，否则您必须自己输入。
Expect 以两种方式深化了这一控制：首先，它提供了表达对话框复杂程度的语言。Expect 不只使用固定“脚本”作为应用程序的输入，而是使交互的每个击键都可编程。
如 Libes 所说，更关键的是：“最终，Expect 是为处理蹩脚的界面而设计的工具。”特别是 Expect 具有管理抵制 I/O 重定向的应用程序的能力。典型示例是命令行 passwd 程序。每个负责管理服务器的人员迟早都需要使密码更新自动化。第一次尝试可能是作为 root 用户运行类似下面的代码：
|
正如每个尝试它的人很快会发现，这根本不起作用。shell 的 < 和 << 重定向对于象 passwd 这样的程序不起作用。
但是，Expect 可以使重定向起作用。Expect 知道如何与所有面向字符的应用程序对话，即使是象passwd 那样操纵终端设置的应用程序。
正是这一点完善了 Expect 的通用性。原则上，其它语言或库可以提供终端特征的信息。例如，Perl 的Expect.pm 模块在这方面已经做了很多。虽然经过十多年生产使用，但却没出现其它有力的竞争对手。
这 就是您应该学习 Expect 的原因。您将处理带有“蹩脚界面”的程序 ― 您周围有很多这样的程序 ― 而 Expect 通过让它们完成您所需的工作，可以减少几小时甚至几天的开发时间。同时，还可以将 Expect 用于通常由 bash 或 Perl 完成的所有作业。
|
|
您还应该了解有关 Expect 的其它信息。本专栏的最后部分包括对 Expect 局限的说明、对解决常见问题的 Expect 工作代码的概述以及可以引导您更深入了解 Expect 编程的参考。
Expect 所做的比大多数人所认识到的要多；这就是本专栏的主题。Expect 也有不足之处。系统程序员通常需要使象 FTP 操作、电子邮件发送或处理以及 GUI 测试这样的任务自动化。对于其中的前两项，Expect 无法提供帮助。更准确地说，虽然可以使用 Expect 来使 FTP 和电子邮件自动化（这样做在前几年也很常见），但是现在 Expect 在这些领域方面没有特别优势。其它语言和方法与面向 Expect 的编码功效相同，或者更胜一筹。这个“服务器诊所”专栏的未来部分将说明简便联网自动化的示例。
Expect 的著名用法是用于测试。Expect 是用于几个高端产品（包括 gcc）质量控制中使用的 DejaGnu 系统的基础。然而，虽然 Expect 可用于构建 GUI，并且在几个测试框架中也很关键，但是通常 Expect 在用于 GUI 系统的测试框架中 不起作用。
暂时回到上面提到的 passwd 问题。Expect 对它的展望是什么呢？
要了解 Expect 源代码，目前更简便的做法是忽略安全性考虑事项。下面的程序需要作为 root 用户运行。Expect 提供有用的功能以实现更安全的操作；不过在掌握 Expect 基础知识后更容易理解这些。
您已经知道简单 I/O 重定向对 passwd 不起作用。何种 Expect 程序提供了更好的结果呢？
|
这就是 Expect 用来使程序自动化所需的全部代码，其它语言几乎不可能做到。再多用几行，您可以一次对成百上千用户进行批处理更新。这是一种常见需求；我经常被请去恢复密码文件被严重毁坏的服务器，这里说明了一种开始的方法：
|
|
|
给 Expect 自动化加上 GUI 外观也只需要多加几行。假定您想为一名非程序员提供方便地更新密码的应用程序。同样忽略安全性考虑事项，这就象完成下列代码一样简单：
|
这个小工作应用程序具有下面的视觉外观：
|
|
Expect 具有系统程序员通常需要的独特能力。同时，Expect 是出色的通用编程语言，它在联网和 GUI 构造方面具有优势。如果您必须只选择一种用于日常工作的语言，Expect 近乎是理想选择。
请告诉我您如何使用 Expect 以及想让它为您做什么。在以后的几个月，这个“服务器诊所”专栏将回头研究高端版本控制、网络代理和更多的自动化。在那以前，祝您和您的服务器都“身体健康”。
|
||
|
Cameron Laird 是 Phaseit, Inc 的一名全职顾问。他经常就开放源码和其它技术主题撰写文章并发表演说。Cameron 感谢 SuSE 的 Reinhard Max 在他准备这个专栏期间所提供的帮助。可以通过claird@phaseit.net与 Cameron 联系。 |
|
