到rpmfind可以下载到expect
#----------------------------------------------
例一：追加到文本前（利用vi）
#!/usr/bin/expect
set a [lindex $argv 0]
set b [lindex $argv 1]
spawn vi $b
expect "*"
send "O"
send "$a"
send "33"
send ":"
send "wq"
send " "
expect eof
[lindex $argv 0] 第一个变量，类似"$1"
[lindex $argv 1] 第二个变量，类似"$2"
#----------------------------------------------
例二：自动su
#!/usr/bin/expect
set password 123
spawn su
expect "*password:"
send "$password "
interact
#----------------------------------------------
例三：passwd tmp用户
#!/usr/bin/expect
spawn passwd tmp
set password 345
expect "*password:"
send "$password "
expect "*password:"
send "$password "
expect eof
 
8.[ftp]
　　我们使用expect写第一个脚本并没有打印出"Hello,World"。实际上，它实现了一些更有用的功能。它能通过非交互的方式来运行ftp。ftp是用来在支持TCP/IP的网络上进行文件传输的程序。除了一些简单的功能，一般的实现都要求用户的参与。
　　下面这个脚本从一个主机上使用匿名ftp取下一个文件来。其中，主机名是第一个参数。文件名是第二个参数。

spawnftp[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
eofbreak
"*UNREF FILE*CLEAR?"{send "r "}
"*BAD INODE*FIX?"{send "y "}
"*?"{send "n "}
}

　 　在下面这个版本里面，两个问题的回答是不同的。而且，如果脚本遇到了什么它不能理解的东西，就会执行interact命令把控制交给用户。用户的击键直 接交给fsck处理。当执行完后，用户可以通过按"+"键来退出或者把控制交还给expect。如果控制是交还给脚本了，脚本就会自动的控制进程的剩余部 分的运行。

for {} {1} {}{
expect
eofbreak
"*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脚本可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将控制返回给键盘。它也可 以在返回控制之前，在循环体和条件测试之间来回的切换