linux下交互式命令expect.docx
- 文档编号:23361638
- 上传时间:2023-05-16
- 格式:DOCX
- 页数:20
- 大小:29.88KB
linux下交互式命令expect.docx
《linux下交互式命令expect.docx》由会员分享,可在线阅读,更多相关《linux下交互式命令expect.docx(20页珍藏版)》请在冰豆网上搜索。
linux下交互式命令expect
[目录]
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 patlist1action1patlist2action2.....
该命令一直等到当前进程的输出和以上的某一个模式相匹配,或者等 到时间超过一个特定的时间长度,或者等到遇到了文件的结束为止。
如果最后一个action是空的,就可以省略它。
每一个patlist都由一个模式或者模式的表(lists)组成。
如果有一个模式匹配成功,相应的action就被执行。
执行的结果从expect返回。
被精确匹配的字符串(或者当超时发生时,已经读取但未进行匹配的字符串)被存贮在变量expect_match里面。
如果patlist是eof或者timeout,则发生文件结束或者超时时才执行相应的action.一般超时的时值是10秒,但可以用类似"settimeout30"之类的命令把超时时值设定为30秒。
下面的一个程序段是从一个有关登录的脚本里面摘取的。
abort是在脚本的别处定义的过程,而其他的action使用类似与C语言的Tcl原语。
expect"*welcome*" break
"*busy*" {printbusy;continue}
"*failed*" abort
timeout abort
模式是通常的CShell风格的正规表达式。
模式必须匹配当前进程的从上一个expect或者interact开始的所有输出(所以统配符*使用的非常)的普遍。
但是,一旦输出超过2000个字节,前面的字符就会被忘记,这可以通过设定match_max的值来改变。
expect命令确实体现了expect语言的最好和最坏的性质。
特别是,expect命令的灵活性是以经常出现令人迷惑的语法做代价。
除了关键字模式(比如说eof,timeout)那些模式表可以包括多个模式。
这保证提供了一种方法来区分他们。
但是分开这些表需要额外的扫描,如果没有恰当的用["]括起来,这有可能会把和当成空白字符。
由于Tcl提供了两种字符串引用的方法:
单引和双引,情况变的更糟。
(在Tcl里面,如果不会出现二义性话,没有必要使用引号)。
在expect的手册里面,还有一个独立的部分来解释这种复杂性。
幸运的是:
有一些很好的例子似乎阻止了这种抱怨。
但是,这个复杂性很有可能在将来的版本中再度出现。
为了增强可读性,在本文中,提供的脚本都假定双引号是足够的。
字符可以使用反斜杠来单独的引用,反斜杠也被用于对语句的延续,如果不加反斜杠的话,语句到一行的结尾处就结束了。
这和Tcl也是一致的。
Tcl在发现有开的单引号或者开的双引号时都会继续扫描。
而且,分号可以用于在一行中分割多个语句。
这乍听起来有点让人困惑,但是,这是解释性语言的风格,但是,这确实是Tcl的不太漂亮的部分。
5.[callback]
令人非常惊讶的是,一些小的脚本如何的产生一些有用的功能。
下面是一个拨电话号码的脚本。
他用来把收费反向,以便使得长途电话对计算机计费。
这个脚本用类似“expectcallback.exp12016442332”来激活。
其中,脚本的名字便是callback.exp,而+1(201)644-2332是要拨的电话号码。
#firstgivetheusersometimetologout
execsleep4
spawntipmodem
expect"*connected*"
send"ATD[index$argv1]"
#modemtakesawhiletoconnect
settimeout60
expect"*CONNECT*"
第一行是注释,第二行展示了如何调用没有交互的Unix程序。
sleep4会使程序阻塞4秒,以使得用户有时间来退出,因为modem总是会回叫用户已经使用的电话号码。
下面一行使用spawn命令来激活tip程序,以便使得tip的输出能够被expect所读取,使得tip能从send读输入。
一旦tip说它已经连接上,modem就会要求去拨打大哥电话号码。
(假定modem都是贺氏兼容的,但是本脚本可以很容易的修改成能适应别的类型的modem)。
不论发生了什么,expect都会终止。
如果呼叫失败,expect脚本可以设计成进行重试,但这里没有。
如果呼叫成功,getty会在expect退出后检测到DTR,并且向用户提示loging:
。
(实用的脚本往往提供更多的错误检测)。
这个脚本展示了命令行参数的使用,命令行参数存贮在一个叫做argv的表里面(这和C语言的风格很象)。
在这种情况下,第一个元素就是电话号码。
方括号使得被括起来的部分当作命令来执行,结果就替换被括起来的部分。
这也和CShell的风格很象。
这个脚本和一个大约60K的C语言程序实现的功能相似。
6.[passwd和一致性检查]
在前面,我们提到passwd程序在缺乏用户交互的情况下,不能运行,passwd会忽略I/O重定向,也不能嵌入到管道里边以便能从别的程序或者文件里读取输入。
这个程序坚持要求真正的与用户进行交互。
因为安全的原因,passwd被设计成这样,但结果导致没有非交互式的方法来检验passwd。
这样一个对系统安全至关重要的程序竟然没有办法进行可靠的检验,真实具有讽刺意味。
passwd以一个用户名作为参数,交互式的提示输入密码。
下面的expect脚本以用户名和密码作为参数而非交互式的运行。
spawnoasswd[index$argv1]
setpassword[index$argv2]
expect"*password:
"
send"$password"
expect"*password:
"
send"$password"
expecteof
第一行以用户名做参数启动passwd程序,为方便起见,第二行把密码存到一个变量里面。
和shell类似,变量的使用也不需要提前声明。
在第三行,expect搜索模式"*password:
",其中*允许匹配任意输入,所以对于避免指定所有细节而言是非常有效的。
上面的程序里没有action,所以expect检测到该模式后就继续运行。
一旦接收到提示后,下一行就就把密码送给当前进程。
表明回车。
(实际上,所有的C的关于字符的约定都支持)。
上面的程序中有两个expect-send序列,因为passwd为了对输入进行确认,要求进行两次输入。
在非交互式程序里面,这是毫无必要的,但由于假定passwd是在和用户进行交互,所以我们的脚本还是这样做了。
最后,"expecteof"这一行的作用是在passwd的输出中搜索文件结束符,这一行语句还展示了关键字的匹配。
另外一个关键字匹配就是timeout了,timeout被用于表示所有匹配的失败而和一段特定长度的时间相匹配。
在这里eof是非常有必要的,因为passwd被设计成会检查它的所有I/O是否都成功了,包括第二次输入密码时产生的最后一个新行。
这个脚本已经足够展示passwd命令的基本交互性。
另外一个更加完备的例子回检查别的一些行为。
比如说,下面的这个脚本就能检查passwd程序的别的几个方面。
所有的提示都进行了检查。
对垃圾输入的检查也进行了适当的处理。
进程死亡,超乎寻常的慢响应,或者别的非预期的行为都进行了处理。
spawnpasswd[index$argv1]
expect eof {exit1}
timeout {exit2}
"*Nosuchuser.*" {exit3}
"*Newpassword:
"
send "[index$argv2"
expect eof {exit4}
timeout {exit2}
"*Passwordtoolong*" {exit5}
"*Passwordtooshort*" {exit5}
"*Retypeewpassword:
"
send"[index$argv3]"
expect timeout {exit2}
"*Mismatch*" {exit6}
"*Passwordunchanged*" {exit7}
""
expect timeout {exit2}
"*" {exit6}
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的POSIX1003.2(shell和工具)的一致性检验所要求的。
进一步的说明请参考Libes[6]。
7.[rogue和伪终端]
Unix用户肯定对通过管道来和其他进程相联系的方式非常的熟悉(比如说:
一个shell管道)。
expect使用伪终端来和派生的进程相联系。
伪终端提供了终端语义以便程序认为他们正在和真正的终端进行I/O操作。
比如说,BSD的探险游戏rogue在生模式下运行,并假定在连接的另一端是一个可寻址的字符终端。
可以用expect编程,使得通过使用用户界面可以玩这个游戏。
rogue这个探险游戏首先提供给你一个有各种物理属性,比如说力量值,的角色。
在大部分时间里,力量值都是16,但在几乎每20次里面就会有一个力量值是18。
很多的rogue玩家都知道这一点,但没有人愿意启动程序20次以获得一个好的配置。
下面的这个脚本就能达到这个目的。
for{}{1}{}{
spawnrogue
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$argv1]
expect "*Name*"
send "anonymous"
expect "*Password:
*"
send[execwhoami]
expect"*ok*ftp>*"
send"get[index$argv2]"
expect"*ftp>*"
上面这个程序被设计成在后台进行ftp。
虽然他们在底层使用和expect类似的机制,但他们的可编程能力留待改进。
因为expect提供了高级语言,你可以对它进行修改来满足你的特定需求。
比如说,你可以加上以下功能:
:
坚持--如果连接或者传输失败,你就可以每分钟或者每小时,甚
至可以根据其他因素,比如说用户的负载,来进行不定期的
重试。
:
通知--传输时可以通过mail,write或者其他程序来通知你,甚至
可以通知失败。
:
初始化-每一个用户都可以有自己的用高级语言编写的初始化文件
(比如说,.ftprc)。
这和Cshell对.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
"*UNREFFILE*CLEAR?
" {send"r"}
"*BADINODE*FIX?
" {send"y"}
"*?
" {send"n"}
}
在下面这个版本里面,两个问题的回答是不同的。
而且,如果脚本遇到了什么它不能理解的东西,就会执行interact命令把控制交给用户。
用户的击键直接交给fsck处理。
当执行完后,用户可以通过按"+"键来退出或者把控制交还给expect。
如果控制是交还给脚本了,脚本就会自动的控制进程的剩余部分的运行。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- linux 交互式 命令 expect