当前位置: 代码迷 >> 综合 >> Expect 教程中文版
  详细解决方案

Expect 教程中文版

热度:51   发布时间:2024-01-13 08:47:46.0

分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

                原贴:http://blog.chinaunix.net/u/13329/showart.php?id=110100

                           
 
                                                                                                               
Expect 教程中文版
 
 
                                                       
                                   
[From] http://www.linuxeden.com/edu/doctext.php?docid=799

  本教程由*葫芦娃*翻译,并做了适当的修改,可以自由的用于非商业目的。

[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的数据文件很有可 能就象下面一样。 <