linu下交互式命令epect

《linu下交互式命令epect》由会员分享，可在线阅读，更多相关《linu下交互式命令epect（13页珍藏版）》请在装配图网上搜索。

1、目录1.摘要2.关键字3. 简介4. Expect 综述5. callback6.passwd 和一致性检查7.rogue 和伪终端8. ftp9. fsck10. 多进程控制：作业控制11.交互式使用 Expect12.交互式 Expect 编程13. 非交互式程序的控制14. Expect 的速度15. 安全方面的考虑16. Expect 资源17.参考书籍1.摘要现代的Shell对程序提供了最小限度的控制（开始，停止，等等），而把交互的特性留给了 用户。 这意味着有些程序，你不能非交互的运行，比如说 passwd。 有一些程序可以非交 互的运行，但在很大程度上丧失了灵活性，比如说fsck

2、。这表明Unix的工具构造逻辑开始 出现问题。Expect恰恰填补了其中的一些裂痕，解决了在Unix环境中长期存在着的一些问 题。Expect使用Tcl作为语言核心。不仅如此，不管程序是交互和还是非交互的，Expect都能 运用。这是一个小语言和Unix的其他工具配合起来产生强大功能的经典例子。本部分教程并不是有关Expect的实现，而是关于Expect语言本身的使用，这主要也是通 过不同的脚本描述例子来体现。其中的几个例子还例证了 Expect的几个新特征。2. 关键字Expect，交互，POSIX，程序化的对话，Shell,Tcl,Unix;3. 简介一个叫做fsck的Unix文件系统检查

3、程序,可以从Shell里面用-y或者-n选项来执行。在 手册1里面，-y选项的定义是象这样的。对于fsck的所有问题都假定一个yes响应；在这样使用的时候，必须特别的小心，因为它实际上允许程序无条件的继续运行，即使是遇到了一些非常严重的错误”相比之下，-n选项就安全的多，但它实际上几乎一点用都没有。这种接口非常的糟糕, 但是却有许多的程序都是这种风格。文件传输程序ftp有一个选项可以禁止交互式的提问， 以便能从一个脚本里面运行。但一旦发生了错误，它没有提供的处理措施。Expect是一个控制交互式程序的工具。他解决了 fsck的问题，用非交互的方式实现了所 有交互式的功能。Expect不是特别为

4、fsck设计的，它也能进行类似ftp的出错处理。fsck和ftp的问题向我们展示了象sh,csh和别的一些shell提供的用户接口的局限性。 Shell 没有提供从一个程序读和象一个程序写的 功能。这意味着 shell 可以运行 fsck 但只能 以牺牲一部分 fsck 的灵活性做代价。有一些程序根本就不能被执行。比如说，如果没有一 个用户接口交互式的提供输入，就没法运行下去。其他还有象Telnet,crypt,su,rlogin等程序 无法在shell脚本里面自动执行。还有很多其他的应用程序在设计是也是要求用户输入的。Expect 被设计成专门针和交互式程序的交互。一个 Expect 程序员

5、可以写一个脚本来描 述程序和用户的对话。接着Expect程序可以非交互的运行交互式”的程序。写交互式程序 的脚本和写非交互式程序的脚本一样简单。Expect还可以用于对对话的一部分进行自动化， 因为程序的控制可以在键盘和 脚本之间进行切换。bes2里面有详细的描述。简单的说，脚本是用一种解释性语言写的。（也有C和C+的Expect 库可供使用，但这超出了本文的范围）.Expect提供了创建交互式进程和读写它们的输入和输 出的命令。Expect是由于它的一个同名的命令而命名的。Expect语言是基于Tcl的。Tcl实际上是一个子程序库，这些子程序库可以嵌入到程序里 从而提供语言服务。 最终的语言

6、有点象一个典型的 Shell 语言。里面有给变量赋值的 set 命令，控制程序执行的if,for,continue等命令，还能进行普通的数学和字符串操作。当然了, 还可以 用 exec 来调用 Unix 程序。所有这些功能， Tcl 都有。 Tcl 在参考书籍 Outerhour34 里有详细的描述。Expect是在Tcl基础上创建起来的，它还提供了一些Tcl所没有的命令。spawn命令激活 一个Unix程序来进行交互式的运行。send命 令向进程发送字符串。expect命令等待进程 的某些字符串。expect支持正规表达式并能同时等待多个字符串，并对每一个字符串执行 不同的操作。expect

7、还能理解一些特殊情况，如超时和遇到文件尾。expect命令和Tcl的case命令的风格很相似。都是用一个字符串去匹配多个字符串。（只 要有可能，新的命令总是和已有的Tcl命令相似，以使得该语言保持工具族的继承性）。下面 关于 expect 的定义是从手册5上摘录下来的。expect patlist1 action1 patlist2 action2该命令一直等到当前进程的输出和以上的某一个模式相匹配，或者等到时间超过一个特定的时间长度，或者等到遇到了文件的结束为止。如果最后一个 action 是空的，就可以省略它。每一个patlist都由一个模式或者模式的表（lists）组成。如果有一个模式匹

8、配成功， 相应的action就被执行。执行的结果从expect返回。被精确匹配的字符串（或者当超时发生时，已经读取但未进行匹配的字符串）被存贮 在变量expect_match里面。如果patlist是eof或者timeout，则发生文件结束或者超时时才执 行相应的action.一般超时的时值是10秒，但可以用类似set timeout 30之类的命令把超时 时值设定为30秒。下面的一个程序段是从一个有关登录的脚本里面摘取的。abort是在脚本的别处定 义的过程，而其他的action使用类似与C语言的Tcl原语。expect *welcome*break*busy*print busy;cont

9、inue*failed*aborttimeoutabort模式是通常的C Shell风格的正规表达式。模式必须匹配当前进程的从上一个expect 或者interact开始的所有输出（所以统配符*使用的非常）的普遍。但是，一旦输出超过2000 个字节，前面的字符就会被忘记，这可以通过设定match_max的值来改变。expect 命令确实体现了 expect 语言的最好和最坏的性质。特别是， expect 命令的灵活 性是以经常出现令人迷惑的语法做代价。除了关键字模 式（比如说eof,timeout那些模式表 可以包括多个模式。这保证提供了一种方法来区分他们。但是分开这些表需要额外的扫描 如果没

10、有恰当的用括起来，这有可能会把和当成空白字符。由于Tcl提供了两种字符串 引用的方法：单引和双引，情况变的更糟。（在Tcl里面，如果不会出现二义性话，没有必 要使用引号）。在expect的手册里面，还有一个独立的部分来解释这种复杂性。幸运的是： 有一些很好的例子似乎阻止了这种抱怨。但是，这个复杂性 很有可能在将来的版本中再度 出现。为了增强可读性，在本文中，提供的脚本都假定双引号是足够的。字符可以使用反斜杠来单独的引用，反斜杠也被用于对语句的延续，如果不加反斜杠的 话，语句到一行的结尾处就结束了。这和Tcl也是一致的。Tcl在发 现有开的单引号或者开 的双引号时都会继续扫描。而且，分号可以用于

11、在一行中分割多个语句。这乍听起来有点让 人困惑，但是，这是解释性语言的风格，但是，这确实是Tcl的不太漂亮的部分。5.callback令人非常惊讶的是，一些小的脚本如何的产生一些有用的功能。下面是一个拨电话号码 的脚本。他用来把收费反向，以便使得长途电话对计算机计费。这个脚本 用类似expect callback.exp 12016442332”来激活。其中，脚本的名字便是 callback.exp，而+1（201）644-2332 是要拨的电话号码。#first give the user some time to logout exec sleep 4spawn tip modemexpe

12、ct *connected*send ATD index $argv 1 #modem takes a while to connectset timeout 60expect *CONNECT*第一行是注释，第二行展示了如何调用没有交互的Unix程序。sleep 4会使程序阻塞4 秒，以使得用户有时间来退出，因为modem总是会回叫用户已经使用的电话号码。下面一行使用spawn命令来激活tip程序，以便使得tip的输出能够被expect所读取， 使得tip能从send读输入。一旦tip说它已经连 接上，modem就会要求去拨打大哥电话号 码。 （假定 modem 都是贺氏兼容的，但是本脚本可

13、以很容易的修改成能适应别的类型的 modem）。不论发生了什么，expect都会终止。如果呼叫失败，expect脚本可以设计成进行 重试，但这里没有。如果呼叫成功，getty会在expect退出后检测到DTR，并且向用户提示 loging:。 （实用的脚本往往提供更多的错误检测）。这个脚本展示了命令行参数的使用，命令行参数存贮在一个叫做argv的表里面（这和C 语言的风格很象）。在这种情况下，第一个元素就是电话号码。方括号使得被括起来的部分 当作命令来执行，结果就替换被括起来的部分。这也和C Shell的风格很象。这个脚本和一个大约60K的C语言程序实现的功能相似。6.passwd 和一致性检

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

15、2 expect *password: send $password expect *password: send $password expect eof第一行以用户名做参数启动passwd程序，为方便起见，第二行把密码存到一个变量里 面。和shell类似，变量的使用也不需要提前声明。在第三行，expect搜索模式Upassword:,其中*允许匹配任意输入，所以对于避免指定 所有细节而言是非常有效的。上面的程序里没有action，所以expect检测到该模式后就继续 运行。一旦接收到提示后，下一行就就把密码送给当前进程。表明回车。 （实际上，所有的 C 的关于字符的约定都支持）。上面的程序

16、中有两个expect- send序列，因为passwd为了对输 入进行确认，要求进行两次输入。在非交互式程序里面，这是毫无必要的，但由于假定passwd 是在和用户进行交 互，所以我们的脚本还是这样做了。最后，expect eof这一行的作用是在passwd的输出中搜索文件结束符，这一行语句还 展示了关键字的匹配。另外一个关键字匹配就是timeout 了，timeout被用于表示所有匹配 的失败而和一段特定长度的时间相匹配。在这里eof是非常有必要的，因为passwd被设计 成会检查它的所有I/O是否 都成功了，包括第二次输入密码时产生的最后一个新行。这个脚本已经足够展示 passwd 命令的

17、基本交互性。另外一个更加完备的例子回检查别 的一些行为。比如说，下面的这个脚本就能检查passwd程序的别的几个方面。所有的提示 都进行了检查。对垃圾输入的检查也进行了适当的处理。进程死亡，超乎寻常的慢响应，或 者别的非预期的行为都进行了处理。spawn passwd index $argv 1 expecteoftimeout*No such user.*New password: send index $argv 2 expecteoftimeout*Password too long*Password too short* *Retype ew password: send index

18、$argv 3 expecttimeout*Mismatch*Password unchanged*exit 1exit 2exit 3exit 4exit 2exit 5exit 5exit 2exit 6exit 7expecttimeoutexit 2*exit 6eof这个脚本退出时用一个数字来表示所发生的情况。0表示passwd程序正常运行，1表示非预期的死亡，2 表示锁定，等等。使用数字是为了简单起见。 expect 返回字符串和返回 数字是一样简单的，即使是派生程序自身产生的消息也是一样的。实际上，典型的做法是把 整个交互的过程存到一个文件里面，只有 当程序的运行和预期一样的时候

19、才把这个文件删 除。否则这个log被留待以后进一步的检查。这个 passwd 检查脚本被设计成由别的脚本来驱动。这第二个脚本从一个文件里面读取 参数和预期的结果。对于每一个输入参数集，它调用第一个脚本并且 把结果和预期的结果 相比较。（因为这个任务是非交互的，一个普通的老式shell就可以用来解释第二个脚本）。比 如说，一个 passwd 的数据文件很有可 能就象下面一样。passwd.exp3boguspasswd.exp0fredabledablabledablpasswd.exp5fredabcdefghijklmpasswd.exp5fredabcpasswd.exp6fredfoob

20、arbarpasswd.exp4fredAC第一个域的名字是要被运行的回归脚本。第二个域是需要和结果相匹配的退出值。第三 个域就是用户名。第四个域和第五个域就是提示时应该输入的密码。减号 仅仅表示那里有 一个域，这个域其实绝对不会用到。在第一个行中， bogus 表示用户名是非法的，因此 passwd 会响应说：没有此用户。expect在退出时会返回3, 3恰好就是第二个域。在最后一行中， y就是被切实的送给程序来验证程序是否恰当的退出。通过这种方法， expect 可以用来检验和调试交互式软件，这恰恰是 IEEE 的 POSIX 1003.2（shell和工具）的一致性检验所要求的。进一步的

21、说明请参考Libes6。7. rogue 和伪终端Unix用户肯定对通过管道来和其他进程相联系的方式非常的熟悉（比如说：一个shell管 道）。 expect 使用伪终端来和派生的进程相联系。伪终端提供了终端语义以便程序认为他们 正在和真正的终端进行I/O操作。比如说，BSD的探险游戏rogue在生模式下运行，并假定在连接的另一端是一个可寻址 的字符终端。可以用expect编程，使得通过使用用户界面可以玩这个游戏。rogue这个探险游戏首先提供给你一个有各种物理属性，比如说力量值，的角色。在大 部分时间里，力量值都是16,但在几乎每20次里面就会有一个力 量值是18。很多的rogue 玩家都知

22、道这一点，但没有人愿意启动程序20次以获得一个好的配置。下面的这个脚本就 能达到这个目的。for 1 spawn roguebreakexpect *Str:18*Str:16* close waitinteract第一行是个for循环，和C语言的控制格式很象。rogue启动后，expect就检查看力量 值是 18 还是 16，如果是 16，程序就通过执行 close 和 wait 来退出。这两个命令的作用分 别是关闭和伪终端的连接和等待进程退出。rogue读到一个文件结束符就推出，从而循环继 续运行，产生一 个新的 rogue 游戏来检查。当一个值为18的配置找到后，控制就推出循环并跳到最后

23、一行脚本。interact把控制转 移给用户以便他们能够玩这个特定的游戏。想象一下这个脚本的运行。你所能真正看到的就是20或者30个初始的配置在不到一秒 钟的时间里掠过屏幕，最后留给你的就是一个有着很好配置的游戏。唯一比这更好的方法就 是使用调试工具来玩游戏。我们很有必要认识到这样一点：rogue是一个使用光标的图形游戏。expect程序员必须 了解到：光标的运动并不一定以一种直观的方式在屏幕上体 现。幸运的是，在我们这个例 子里，这不是一个问题。将来的对expect的改进可能会包括一个内嵌的能支持字符图形区 域的终端模拟器。8. ftp我们使用expect写第一个脚本并没有打印出Hello/

24、World。实际上，它实现了一些更有 用的功能。它能通过非交互的方式来运行ftp。ftp是用来在支持TCP/IP的网络上进行文件传 输的程序。除了一些简单的功能，一般的实现都要求用户的参与。下面这个脚本从一个主机上使用匿名ftp取下一个文件来。其中，主机名是第一个参数。 文件名是第二个参数。spawnftpindex $argv 1expect *Name* sendanonymous expect *Password:* send exec whoami expect *ok*ftp* send get index $argv 2 expect *ftp*上面这个程序被设计成在后台进行ftp

25、。虽然他们在底层使用和expect类似的机制，但 他们的可编程能力留待改进。因为 expect 提供了高级语言，你可以对它进行修改来满足你 的特定需求。比如说，你可以加上以下功能：坚持如果连接或者传输失败，你就可以每分钟或者每小时，甚 至可以根据其他因素，比如说用户的负载，来进行不定期的 重试。:通知传输时可以通过mail,write或者其他程序来通知你，甚至可以通知失败。:初始化每一个用户都可以有自己的用高级语言编写的初始化文件（比如说，.ftprc）。这和C shell对.cshrc的使用很类似。expect还可以执行其他的更复杂的任务。比如说，他可以使用McGill大学的Archie系

26、统。Archie是一个匿名的Telnet服务，它 提供对描述Internet上可通过匿名ftp获取的文件 的数据库的访问。通过使用这个服务，脚本可以询问Archie某个特定的文件的位置，并把 它从 ftp 服务器上取下来。这个功能的实现只要求在上面那个脚本中加上几行就可以。现在还没有什么已知的后台-ftp能够实现上面的几项功能，能不要说所有的功能了。在 expect里面，它的实现却是非常的简单。坚持”的实现只要 求在expect脚本里面加上一个 循环。通知的实现只要执行mail和write就可以了。初始化文件的实现可以使用一个命 令，source .ftprc，就可以了，在.ftprc里面可以

27、有任何的expect命令。虽然这些特征可以通过在已有的程序里面加上钩子函数就可以，但这也不能保证每一个 人的要求都能得到满足。唯一能够提供保证的方法就是提供一种通用的语 言。一个很好的 解决方法就是把Tcl自身融入到ftp和其他的程序中间去。实际上，这本来就是Tcl的初衷。 在还没有这样做之前，expect提供了一个能实现大部分功能但又不需要任何重写的方案。9. fsckfsck 是另外一个缺乏足够的用户接口的例子。 fsck 几乎没有提供什么方法来预先的回答 一些问题。你能做的就是给所有的问题都回答yes或者都回答no。下面的程序段展示了一个脚本如何的使的自动的对某些问题回答yes，而对某些

28、问题 回答no。下面的这个脚本一开始先派生fsck进程，然后对其中两种类型的问题回答yes， 而对其他的问题回答no。for 1 expecteofbreak*UNREF FILE*CLEAR?send r *BAD INODE*FIX?send y *?send n 在下面这个版本里面，两个问题的回答是不同的。而且，如果脚本遇到了什么它不能理 解的东西，就会执行 interact 命令把控制交给用户。用户的击键 直接交给 fsck 处理。当执 行完后，用户可以通过按+键来退出或者把控制交还给expect。如果控制是交还给脚本了，脚本就会自动的控制进程的剩余 部分的运行。for 1 expec

29、teof break*UNREF FILE*CLEAR?send y *BAD INODE*FIX? send y *? interact +如果没有expect, fsck只有在牺牲一定功能的情况下才可以非交互式的运行。fsck几乎 是不可编程的，但它却是系统管理的最重要的工具。许多别的工具的用户接口也一样的不足 实际上，正是其中的一些程序的不足导致了 expect的诞生。10.控制多个进程：作业控制expect 的作业控制概念精巧的避免了通常的实现困难。其中包括了两个问题：一个是 expect如何处理经典的作业控制，即当你在终端上按下T键时expect如何处理；另外一个 就是 expect

30、 是如何处理多进程的。对第一个问题的处理是：忽略它。 expect 对经典的作业控制一无所知。比如说，你派生 了一个程序并且发送一个T给它,它就会停下来（这是伪终端的完美之处）而expect就会永远 的等下去。但是，实际上，这根本就不成一个问题。对于一个expect脚本，没有必要向进程发送T。 也就是说，没有必要停下一个进程来。expect仅仅是忽略了一个进程，而把自己的注意力转 移到其他的地方。这就是expect的作业控制思想，这个思想也一直工作的很好。从用户的角度来看是象这样的：当一个进程通过spawn命令启动时，变量spawn_id就 被设置成某进程的描述符。由 spawn_id 描述的

31、进程就 被认为是当前进程。 （这个描述符恰 恰就是伪终端文件的描述符，虽然用户把它当作一个不透明的物体）。expect和send命令仅 仅和当前进程进行交互。 所以，切换一个作业所需要做的仅仅是把该进程的描述符赋给 spawn_id。这儿有一个例子向我们展示了如何通过作业控制来使两个chess进程进行交互。在派生 完两个进程之后，一个进程被通知先动一步。在下面的循环里面，每 一步动作都送给另外 一个进程。其中， read_move 和 write_move 两个过程留给读者来实现。 （实际上，它们的实 现非常的容易，但是，由于太长 了所以没有包含在这里）。;# start player one

32、;# force it to go firstspawn chessset id1$spawn_idexpect Chess send first read_move spawn chess ;# start player twoset id2 $spawn_idexpect Chess for 1 send_moveread_moveset spawn_id $id1send_move read_move set spawn_id $id2有一些应用程序和 chess 程序不太一样，在 chess 程序里，的两个玩家轮流动。下面这 个脚本实现了一个冒充程序。它能够控制一个终端以便用户能够登录

33、 和正常的工作。但是， 一旦系统提示输入密码或者输入用户名的时候，expect就开始把击键记下来，一直到用户按 下回车键。这有效的收集了用户的密码和用 户名，还避免了普通的冒充程序的 Incorrect password-tryagain。而且，如果用户连接到另外一个主机上，那些额外的登录也会被记录下 来。spawn tip /dev/tty17;# open connection toset tty $spawn_id;# tty to be spoofedspawn loginset login $spawn_idlog_user 0for 1 set ready select $tty

34、$logincase $login in $ready set spawn_id $loginexpect*password* *login*send_user $expect_matchset log 1*;# ignore everything elseset spawn_id$tty;send $expect_matchcase $tty in $ready set spawn_idexpect * *$ttyif $log send_user $expect_match set log 0II * IIsend_user $expect_match$login;set spawn_id

35、send $expect_match这个脚本是这样工作的。首先连接到一个login进程和终端。缺省的，所有的对话都记 录到标准输出上（通过send_user）。因为我们对此并不感兴趣,所以，我们通过命令log_user 0来禁止这个功能。 （有很多的命令来控制可以看见或者可以记录的东西）。在循环里面， select 等待终端或者 login 进程上的动作，并且返回一个等待输入的 spawn_id表。如果在表里面找到了一个值的话，case就执 行一个action。比如说，如果字 符串login出现在login进程的输出中，提示就会被记录到标准输出上，并且有一个标志被 设置以便通知脚本开 始记录用

36、户的击键，直至用户按下了回车键。无论收到什么，都会回 显到终端上，一个相应的 action 会在脚本的终端那一部分执行。这些例子显示了 expect的作业控制方式。通过把自己插入到对话里面，expect可以在 进程之间创建复杂的I/O流。可以创建多扇出，复用扇入的，动态的数据相关的进程图。相比之下，shell使得它自己一次一行的读取一个文件显的很困难。shell强迫用户按下 控制键（比如，AC/Z）和关键字（比如馆和bg）来实现作业的切换。这些都无法从脚本里面利 用。相似的是：以非交互方式运行的 shell 并不处理“历史记录”和其他一些仅仅为交互式使 用设计的特征。这也出现了和前面哪个pas

37、swd程序的相似问题。相似的，也无法编写能够 回归的测试shell的某些动作的shell脚本。结果导致shell的这些方面无法进行 彻底的测试。如果使用expect的话，可以使用它的交互式的作业控制来驱动shell。一个派生的shell 认为它是在交互的运行着，所以会正常的处理作业控制。它 不仅能够解决检验处理作业控 制的shell和其他一些程序的问题。还能够在必要的时候，让shell代替expect来处理作业。 可以支持使用shell风格的作业控制来支持进程的运行。这意味着：首先派生一个shell，然 后把命令送给shell来启动进程。如果进程被挂起，比如说，发送了一个Z,进程就会停下 来，

38、并把控制返回给shell。对于expect而言，它还在处理同一个进程（原来那个shell）。expect 的解决方法不仅具有很大的灵活性，它还避免了重复已经存在于 shell 中的作业 控制软件。通过使用shell，由于你可以选择你想派生的shell，所以你可以根据需要获得作 业控制权。而且，一旦你需要（比如说检验的时候），你就可以驱动一个shell来让这个shell 以为它正在交互式 的运行。这一点对于在检测到它们是否在交互式的运行之后会改变输出 的缓冲的程序来说也是很重要的。为了进一步的控制，在interact执行期间，expect把控制终端（是启动expect的那个终 端，而不是伪终端）

39、设置成生模式以便字符能够正确的传送给派生的进程。当expect在没有 执行interact的时候，终端处于熟模式下，这时候作业控制就可以作用于expect本身。11.交互式的使用 expect在前面，我们提到可以通过 interact 命令来交互式的使用脚本。基本上来说， interact 命令提供了对对话的自由访问，但我们需要一些更精细 的控制。这一点，我们也可以使用 expect 来达到，因为 expect 从标准输入中读取输入和从进程中读取输入一样的简单。 但是， 我们要使用expect_user和send_user来进行标准I/O,同时不改变spawn_id。下面的这个脚本在一定的时间

40、内从标准输入里面读取一行。这个脚本叫做timed_read, 可以从csh里面调用，比如说，set answer=timed_read 30就能调用它。#!/usr/local/bin/expect -fset timeout index $argv 1expect_user * send_user $expect_match第三行从用户那里接收任何以新行符结束的任何一行。最后一行把它返回给标准输出。 如果在特定的时间内没有得到任何键入，则返回也为空。第一行支持#!的系统直接的启动脚本。 （如果把脚本的属性加上可执行属性则不要在 脚本前面加上expect）o当然了脚本总是可以显式的用expec

41、t scripot来启动。在-c后面的 选项在任何脚本语句执行前就被执行。比如说，不要修改脚本本身，仅仅在命令行上加上c trace.，该脚本可以加上trace功能了（省略号表示trace的选项）。在命令行里实际上可以加上多个命令，只要中间以;分开就可以了。比如说，下面这 个命令行：expect -c set timeout 20;spawn foo;expect一旦你把超时时限设置好而且程序启动之后， expect 就开始等待文件结束符或者 20 秒的超时时限。如果遇到了文件结束符（EOF）,该程序就会停下来，然后expect返回。如果 是遇到了超时的情况，expect就返回。在这两中情况里

42、面，都隐式的杀死了当前进程。如果我们不使用expect而来实现以上两个例子的功能的话，我们还是可以学习到很多 的东西的。在这两中情况里面，通常的解决方案都是fork另一个睡眠的子进程并且用signal 通知原来的shell。如果这个过程或者读先发生的话，shell就会杀司那个睡眠的进程。传递 pid和防止后台进程产生启动信息是一个让除了高手级shell程序员之外的人头痛的事情。提 供一个通用的方法来象这样启动多个进程会使 shell 脚 本非常的复杂。 所以几乎可以肯定 的是，程序员一般都用一个专门C程序来解决这样一个问题。expect_user,send_user,send_error向标准

43、错误终端输出)在比较长的，用来把从进程来 的复杂交互翻译成简单交互的 expect 脚本里面使用的比较频繁。在参考7里面， Libs 描述 怎样用脚本来安全的包裹(wrap)adb,怎样把系统管理员从需要掌握adb的细节里面解脱出 来，同时大大的降低了由于错误的击键而导致的系统崩溃。一个简单的例子能够让ftp自动的从一个私人的帐号里面取文件。在这种情况里，要 求提供密码。 即使文件的访问是受限的，你也应该避免把密码以明文的方式存储在文件里 面。把密码作为脚本运行时的参数也是不合适的，因为用ps命令能看到它们。有一个解决 的方法就是在脚本运行的开始调用expect_user来让用户输入以后可能使

44、用的密码。这个密 码必须只能让这个脚本知道，即使你是每个小时都要重试 ftp。即使信息是立即输入进去的，这个技巧也是非常有用。比如说，你可以写一个脚本， 把你每一个主机上不同的帐号上的密码都改掉，不管他们使用的是不是同 一个密码数据库。 如果你要手工达到这样一个功能的话，你必须Telnet到每一个主机上，并且手工输入新的密 码。而使用expect，你可以只输入密码一次而让脚本来做其它的事情。expect_user和interact也可以在一个脚本里面混合的使用。考虑一下在调试一个程序 的循环时，经过好多步之后才失败的情况。一个expect脚本可以驱动哪个调试器，设置好 断点，执行该程序循环的若干步，然后将控制返回给键盘。它也可以在返回控制之前，在循 环体和条件测试之间来回 的切换.