for line in lines:
item = line.split('\t')
print item

结果是：

['a@qq.com', '111\n']
['b@qq.com', '4214312\n']
['c@qq.com', '3214\n']
['cc@qq.com', '432\n']
['a@qq.com', '43\n']

list最后一个元素多一个了\n
这显然不是我们要的结果。
解决方案，简单地把\n删除就好了：
tempfile = open('./dicttest.txt','r')
lines = tempfile.readlines()
tempfile.close()

for line in lines:
item = line.strip('\n').split('\t')
print item


嗯
大概记录下，省得下次再走弯路。

想不出来是什么问题，为什么一定要从硬盘引导起来才可以顺利安装。

PS:软改bios的方式激活还不错。

bash:

Ctrl-A 相当于HOME键，用于将光标定位到本行最前面
Ctrl-E 相当于End键，即将光标移动到本行末尾
Ctrl-K 用于删除从光标处开始到结尾处的所有字符
Ctrl-L 清屏，相当于clear命令
Ctrl-R 进入历史命令查找状态，然后你输入几个关键字符，就可以找到你使用过的命令
Ctrl-U 用于删除从光标开始到行首的所有字符。一般在密码或命令输入错误时常用
Ctrl-W 用于删除当前光标左侧的一个单词
bind -P命令可以查看所有键盘绑定。

vim:
vim太多了，我只记住几个我一直记不住的定位快捷键

按数字「0」：移到文章的开头。
按「G」：移动到文章的最后。
按「$」：移动到光标所在行的“行尾”。
按「^」：移动到光标所在行的“行首”
按「w」：光标跳到下个字的开头
按「e」：光标跳到下个字的字尾
按「b」：光标回到上个字的开头

函数调用
downlog ${Ip} ${Port} ${User} ${Pass} ${FileName} ${LocalName}

当然，如果你是多文件下载，例如做目录同步，建议使用lftp
lftp -u user,passwd -e "mirror -R ‘$path’ –ignore-time –verbose && quit" IP

依稀记得在公司的时候无线连接是没有问题的
于是去掉无线路由器
又回到了飞快的感觉

一周后
再次折腾无线路由器
发现只要把路由器无线的规模强制为802.11g
就不会有问题了

嗯
还是无线好用
不需要插线不需要拨号

UPDATE wp_posts SET post_content=REPLACE(post_content,'\"attachments','\"/attachments');

趁机学习了一下搞懂了当初笔试没弄明白的一个问题

有下面一个文本，包含两个字段，邮箱、发送邮件字节数，分别求出每个邮箱发送字节数总和及平均数
a.txt

42116 tengxun@qq.com
41288 tengyzw@qq.com
41017 tengxun@qq.com
489389 abc@qq.com
848 fkj@qq.com
322 abc@qq.com
904 fkj@qq.com

如果不用关联数组
你可以把不同的邮箱记录提取到不同的文件中然后求和及平均，显然这很麻烦
awk一条命令搞定
cat a.txt |awk ‘{sum[$2]+=$1;count[$2]++}END{for (i in sum) print i,sum[i], sum[i]/count[i] }’
这条简短的语句包含了很多功能，sum[$2]+=$1创建了一个以邮箱字符串为索引的数组并且把不同邮箱的发送字节数求和，count[$2]++则对邮箱出现的次数做了计数相当于uniq -c。
显示结果如下：第一列为邮箱名 第二列为和发送字节数总和 第三列为平均字节数
abc@qq.com 489711 244856
tengyzw@qq.com 41288 41288
tengxun@qq.com 83133 41566.5
fkj@qq.com 1752 876

如果某项请求发送到您的服务器要求显示您网站上的某个网页（例如，用户通过浏览器访问您的网页或 Googlebot 抓取网页时），服务器将会返回 HTTP 状态代码以响应请求。

此状态代码提供关于请求状态的信息， 告诉 Googlebot 关于您的网站和请求的网页的信息。

一些常见的状态代码包括：

• 200 – 服务器成功返回网页
• 404 – 请求的网页不存在
• 503 – 服务器暂时不可用

下面提供 HTTP 状态代码的完整列表。 点击链接可了解详情。 您也可以访问有关 HTTP 状态代码的 W3C 网页以获得更多信息。

1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。

代码 说明
100（继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101（切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。

2xx（成功）

表示服务器成功处理了请求的状态代码。

代码 说明
200（成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。 如果针对您的 robots.txt 文件显示此状态，则表示 Googlebot 已成功检索到该文件。
201（已创建） 请求成功并且服务器创建了新的资源。
202（已接受） 服务器已接受请求，但尚未处理。
203（非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204（无内容） 服务器成功处理了请求，但没有返回任何内容。
205（重置内容） 服务器成功处理了请求，但没有返回任何内容。 与 204 响应不同，此响应要求请求者重置文档视图（例如，清除表单内容以输入新内容）。
206（部分内容） 服务器成功处理了部分 GET 请求。

3xx（重定向）
要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。 Google 建议您在每次请求中使用重定向不要超过 5 次。 您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。 诊断下的网络抓取页面列出了由于重定向错误而导致 Googlebot 无法抓取的网址。

代码 说明
300（多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者（用户代理）选择一项操作，或提供操作列表供请求者选择。
301（永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。 您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。
302（暂时移动） 服 务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 或 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动，因为 Googlebot 会继续抓取原有位置并编入索引。
303（查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。 对于除 HEAD 之外的所有请求，服务器会自动转到其他位置。
304（未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。 由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销

。

305（使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307（暂时重定向） 服 务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。 此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置，但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动，因为 Googlebot 会继续抓取原有位置并编入索引。

4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。

代码 说明
400（错误请求） 服务器不理解请求的语法。
401（未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403（禁止） 服务器拒绝请求。 如果您看到 Googlebot 在尝试抓取您网站上的有效网页时收到此状态代码（可以在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息），可能是您的服务器或主机拒绝 Googlebot 访问。
404（未找到） 服务器找不到请求的网页。 例如，如果请求服务器上不存在的网页，服务器通常会返回此代码。

如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具”诊断”标签的 robots.txt 页上看到此状态，那么这是正确的状态。 但是，如果您有 robots.txt 文件而又看到此状态，则说明您的 robots.txt 文件可能命名错误或位于错误的位置 （该文件应当位于顶级域名，名为 robots.txt）。

如果您看到有关 Googlebot 尝试抓取的网址的此状态（在”诊断”标签的 HTTP 错误页上），则表示 Googlebot 追踪的可能是另一个页面的无效链接（是旧链接或输入有误的链接）。

405（禁用的方法） 禁用请求中指定的方法。
406（不可接受） 无法使用请求的内容特性响应请求的网页。
407（需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。 如果服务器返回此响应，还会指明请求者应当使用的代理。
408（请求超时） 服务器等候请求时发生超时。
409（冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。 服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会附上两个请求的差异列表。
410（已删除） 如果请求的资源已永久删除，服务器就会返回此响应。 该代码与 404（未找到）代码相似，但在资源以前存在而现在不存在的情况下，有时会用来替代 404 代码。 如果资源已永久删除，您应当使用 301 指定资源的新位置。
411（需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413（请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415（不支持的媒体类型） 请求的格式不受请求页面的支持。
416（请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417（未满足期望要求） 服务器未满足”期望”请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

代码 说明
500（服务器内部错误） 服务器遇到错误，无法完成请求。
501（尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502（错误网关） 服务器充当网关或代理，从上游服务器收到无效响应。
503（服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504（网关超时） 服务器充当网关或代理，但没有及时从上游服务器收到请求。
505（HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

Web压力测试工具介绍

http_load -parallel 5 -fetches 1000 urls.txt
http_load -rate 2 -seconds 300 urls.txt

http_load -rate 5 -seconds 10 urls
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
HTTP response codes:
code 200 -- 49

ab -n 1000 -c 50 http://www.domain.com/myapp.php

Server Software:        nginx/0.6.25
Server Hostname:        www.domain.com
Server Port:            80

Document Path:          /myapp.php
Document Length:        37899 bytes

Concurrency Level:      100
Time taken for tests:   26.507540 seconds
Complete requests:      2000
Failed requests:        14
   (Connect: 0, Length: 14, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    0
Total transferred:      75931178 bytes
HTML transferred:       75439670 bytes
Requests per second:    75.45 [#/sec] (mean)
Time per request:       1325.377 [ms] (mean)
Time per request:       13.254 [ms] (mean, across all concurrent requests)
Transfer rate:          2797.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       24  640 1310.9     34    7478
Processing:    86  590 2230.9    124   23256
Waiting:        0   55 207.7     41    8292
Total:        112 1230 2501.0    169   23304

离开上家公司后
没怎么摆弄openvpn了
最近看到主页上有更新
最新的版本为2.1 rc10
仔细看了一下更新中有一个很有意思的特性

topology subnet feature, allowing intuitive tun-based VPN subnets having 1 IP address per client.

这个特性应该在2.1版本中很早就有
不过一直没有注意到
使用这个特性后，在tun模式下，就不需要每个客户端占用/30大小的子网了，确实很棒，因为之前公司使用openvpn作大规模部署中因为/30子网这个问题带来不少麻烦，现在都解决了。

man page中这样描述

–topology mode
              Configure virtual addressing topology when running in –dev tun mode.  This directive  has  no  meaning  in
              –dev tap mode, which always uses a subnet topology.

              If  you  set  this  directive on the server, the –server and –server-bridge directives will automatically
              push your chosen topology setting to clients as well.  This  directive  can  also  be  manually  pushed  to
              clients.  Like the –dev directive, this directive must always be compatible between client and server.

              mode can be one of:

              net30 — Use a point-to-point topology, by allocating one /30 subnet per client.  This is designed to allow
              point-to-point semantics when some or all of the connecting clients might be Windows systems.  This is  the
              default on OpenVPN 2.0.

              p2p  — Use a point-to-point topology where the remote endpoint of the client’s tun interface always points
              to the local endpoint of the server’s tun interface.  This mode allocates a single IP address per  connect-
              ing  client.   Only use when none of the connecting clients are Windows systems.  This mode is functionally
              equivalent to the –ifconfig-pool-linear directive which is available in OpenVPN 2.0 and is now deprecated.

              subnet  — Use a subnet rather than a point-to-point topology by configuring the tun interface with a local
              IP address and subnet mask, similar to the topology used in –dev tap and  ethernet  bridging  mode.   This
              mode allocates a single IP address per connecting client and works on Windows as well.  Only available when
              server and clients are OpenVPN 2.1 or higher, or OpenVPN 2.0.x which has been  manually  patched  with  the
              –topology  directive  code.  When used on Windows, requires version 8.2 or higher of the TAP-Win32 driver.
              When used on *nix, requires that the tun driver supports an ifconfig(8) command which sets a subnet instead
              of a remote endpoint IP address.

              This option exists in OpenVPN 2.1 or higher.

$0
shell或shell脚本的名字
$*
以一对双引号给出参数列表
$@
将各个参数分别加双引号返回
$#
参数的个数
$_
代表上一个命令的最后一个参数
$$
代表所在命令的PID
$!
代表最后执行的后台命令的PID
$?
代表上一个命令执行后的退出状态

PS:使用这个脚本的前提是,你要在iptables规则中输出日志,并给日志加上形如log-prefix ‘Firewall ‘的前缀,注意引号里面单词后面有一个空格.否则可能得不到脚本预期的输出结果.

    文件名:fwlog

    用途:     根据条件分析处理iptables日志，只输出我们关心的内容以方便查看
    输入格式为  Apr 11 13:40:04 iptablesforward SRC=192.168.39.67 DST=74.220.215.221 PROTO=TCP SPT=1081 DPT=80

    用法:     chmod +x fwlog

          ./fwlog  [-l language] [-h help] [-s SRC] [-d DST] [-S SPT]
           [-D DPT] [-t time] [-m mark] [-p protocol] [-i inputfilename]
           [-o inputfilename]
            -l 结果显示的语言 en 为英语,chs为中文.
            -h 显示帮助
            -s 源IP 形如192.168.1.1
            -d 目的IP
            -S 源端口 形如80
            -D 目的端口 形如80
            -p 协议类型 形如TCP(大写)
            -m iptables chain标识(需要自己在日志中自定义)
            -i 日志文件所在路径
            -o 处理脚本输出路径 不选则输出到屏幕
    日期:     2008年4月8日
    版本:     version 0.9 build 20080408

 #! /bin/bash
##############################################################################
##
## 文件名:   fwlog�
## 用途:     根据条件分析处理iptables日志
## 用法:     chmod +x fwlog;
##          ./fwlog  [-l language] [-h help] [-s SIP] [-d DIP] [-S SPT]
##          [-D DPT] [-t time] [-c chain] [-p protocol]
##          -l 结果显示的语言 en 为英语,chs为中文
##          -h 显示帮助
##          -s 源IP 形如192.168.1.1
##          -d 目的IP
##          -S 源端口 形如80
##          -D 目的端口 形如80
##          -p 协议类型 形如TCP(大写)
##          -m iptables日志标识(需要自己在日志中自定义)
##          -m iptables chain标识(需要自己在日志中自定义)
##          -i 日志文件所在路径
##          -o 处理脚本输出路径 不选则输出到屏幕
##
## 日期:     2008年4月8日
## 版本:     version 0.9 build 20080408
## MailTo: �
##
##############################################################################
# common location
DATUM=`date +%Y%m%d%H%M%S`

# parse args
loglanguage=
prog=`basename $0`
SIP=
DIP=
SPT=
time=
markstring=
protocol=
datum=
file=
outputfilename=
inputfilename=

usage()
{
    echo “    文件名:   fwlog                                                         �
    用途:     根据条件分析处理iptables日志，只输出我们关心的内容以方便查看
    输入格式为  Apr 11 13:40:04 iptablesforward SRC=192.168.39.67 DST=74.220.215.221 PROTO=TCP SPT=1081 DPT=80
    用法:     chmod +x fwlog; �
          ./fwlog  [-l language] [-h help] [-s SRC] [-d DST] [-S SPT]
           [-D DPT] [-t time] [-m mark] [-p protocol] [-i inputfilename]
           [-o inputfilename]
            -l 结果显示的语言 en 为英语,chs为中文
            -h 显示帮助
            -s 源IP 形如192.168.1.1
            -d 目的IP
            -S 源端口 形如80
            -D 目的端口 形如80
            -p 协议类型 形如TCP(大写)
            -m iptables chain标识(需要自己在日志中自定义)
            -i 日志文件所在路径
            -o 处理脚本输出路径 不选则输出到屏幕
    日期:     2008年4月8日
    版本:     version 0.9 build 20080408 ”  

}

if [ -z "$1" ]; then
    usage; exit 1
fi
while getopts l:s:S:d:D:t:m:p:i:o:h opt ; do
 case “$opt” in
 l) loglanguage=”$OPTARG” ;;
 s) SRC=\|grep\ SRC=”$OPTARG” ;;
 S) SPT=\|grep\ SPT=”$OPTARG” ;;
 d) DST=\|grep\ DST=”$OPTARG” ;;
 D) DPT=\|grep\ DPT=”$OPTARG” ;;
 p) protocol=\|grep\ PROTO=”$OPTARG” ;;
    t) time=\|grep\ “$OPTARG” ;;
 m) markstring=\|grep\ “$OPTARG” ;;
 o) outputfilename=”> $OPTARG” ;;
 i) inputfilename=”$OPTARG” ;;
 h) usage; exit 0 ;;
 *) usage; exit 1 ;;
 esac
done
if [ -z "$inputfilename" ]; then
    usage;echo “!!!!!!请输入日志文件路径!1!!!!!!!!”;exit 1
fi

grepstring=”grep SRC $inputfilename |grep DF |sed ‘s/\[.*\]//g’|grep -v MAC $SRC $SPT $DST $DPT $protocal $time $markstring  | awk ‘{print \$1 \” \”\$2\” \”\$3\” \”\$6\” \”\$9\” \”\$10\” \”\$17\” \”\$18\” \”\$19 }’ $outputfilename”
if [ -z "$outputfilename" ]; then
    grepstringnodf=”grep SRC $inputfilename |grep -v DF |sed ‘s/\[.*\]//g’|grep -v MAC $SRC $SPT $DST $DPT $protocal $time $markstring  | awk ‘{print \$1 \” \”\$2\” \”\$3\” \”\$6\” \”\$9\” \”\$10\” \”\$16\” \”\$17\” \”\$18 }’ $outputfilename”

    grepstringmac=”grep SRC $inputfilename |grep MAC |sed ‘s/\[.*\]//g’$SRC $SPT $DST $DPT $protocal $time $markstring  | awk ‘{print \$1 \” \”\$2\” \”\$3\” \”\$6\” \”\$10\” \”\$11\” \”\$18\” \”\$19\” \”\$20 }’ $outputfilename”
else
    grepstringnodf=”grep SRC $inputfilename |grep -v DF |sed ‘s/\[.*\]//g’|grep -v MAC $SRC $SPT $DST $DPT $protocal $time $markstring  | awk ‘{print \$1 \” \”\$2\” \”\$3\” \”\$6\” \”\$9\” \”\$10\” \”\$16\” \”\$17\” \”\$18 }’ >$outputfilename”

    grepstringmac=”grep SRC $inputfilename |grep MAC |sed ‘s/\[.*\]//g’$SRC $SPT $DST $DPT $protocal $time $markstring  | awk ‘{print \$1 \” \”\$2\” \”\$3\” \”\$6\” \”\$10\” \”\$11\” \”\$18\” \”\$19\” \”\$20 }’ >$outputfilename”
fi
bash -c “$grepstring”
bash -c “$grepstringnodf”
bash -c “$grepstringmac”

总的来说，这种安装方式还是很不错的，不用分区，不用搞那些乱七八糟的引导，像装个应用程序那么简单。
实际运行的性能，没感觉到有太大的损失，或许我这种普通的应用感觉不出性能，又或许我的破笔记本没有性能可言。

Linux下比较大的问题就是中文字体的问题，wqy字体渲染太耗cpu，还好有雅黑，虽然不是那么纯粹的linux主义，但总算让自己的眼睛舒服了很多。

Anyway,尽管大家对于ubuntu有各种各样的争议，我觉得我们都应该感谢ubuntu在linux桌面化做出的努力。

顺便期待一下ubuntu 8.04的正式版。

当然，我还是要抱怨一下，ubuntu那黄色的主题真是难看，而且我安装其它主题总是费了很大劲还是不能彻底地去掉那些黄色。

我们需要操作记录
但尽管我们给每个人分配了用户
但进行的一个系统管理操作都会切换到root用户进行
光看history显然不行
而且更为糟糕的是history是一个极易删除的东西

如果你有这样的烦恼
那么下面的方法或许适合你

script可以录制屏幕
你可以自己写一个脚本使用script来录制屏幕并生成对应的文件最后输出到一个只有少数人有权限的服务器上
然后在/etc/bash.bashrc里加载这个脚本
这样就实现了每个用户只要登录
屏幕信息就被记录

当然如果你仔细去推敲的话你会发现这种方法只能防君子不能防小人
呵呵

1. vmware workstation,看名字就知道他是一个适合于单机工作站的版本.他的虚拟子系统的安装必须在宿主系统里完成.vmware server (前身为vmware gsx server)则主要改进了远程控制方面,适用于工作组.他的子系统安装和控制都可以远程进行.而vmware esx server则是企业级的虚拟化解决方案,功能也是最强大,性能也是最好的.

2.vmware workstation和vmware server都可以认为是一个应用程序,他需要安装于一个宿主系统.而vmware esx server我们可以认为他本身就是一个操作系统,他直接安装于裸机,子系统运行于vmware esx server之上.这就不难理解vmware esx server为什么性能是最高了,但同时他也会要求你的硬件足够强大.

3.vmware server 是免费的,可以到官方网站上申请序列号. vmware esx server则需要高昂的费用方可使用.

就是这么简单!

关键字：无人值守 linux安装

方法：使用kickstart 建立ks.cfg,然后安装时使用linux ks=XXX:/ks.cfg 

尽情发挥你的想象力，XXX处使用你想用的媒体。

我们通过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。

QUOTE:
Login: somebody Password: sillyme
这个脚本用来实现一个登录过程，并用特定的用户名和密码实现登录。

Expect最简单的脚本操作模式本质上和Chat脚本工作模式是一样的。

例子：
1、实现功能
下面我们分析一个响应chsh命令的脚本。我们首先回顾一下这个交互命令的格式。假设我们要为用户chavez改变登录脚本，要求实现的命令交互过程如下：

QUOTE:
# 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。

2、下面是一个能用来实现自动执行该命令的Expect脚本：

[Copy to clipboard] [ - ]CODE:
#!/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脚本也就退出结束。

3、决定如何响应

管理员往往有这样的需求，希望根据当前的具体情况来以不同的方式对一个命令进行响应。我们可以通过后面的例子看到expect可以实现非常复杂的条件响应，而仅仅通过简单的修改预处理脚本就可以实现。下面的例子是一个更复杂的expect-send例子：

[Copy to clipboard] [ - ]CODE:
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包含有整个匹配输出)。()可能会出现嵌套情况，这这种情况下编码从最内层到最外层来进行的。

4、使用超时

下一个expect例子中将阐述具有超时功能的提示符函数。这个脚本提示用户输入，如果在给定的时间内没有输入，则会超时并返回一个默认的响应。这个脚本接收三个参数：提示符字串，默认响应和超时时间(秒)。

[Copy to clipboard] [ - ]CODE:
#!/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]
脚本的第一部分首先是得到运行参数并将其保存到内部变量中。

[Copy to clipboard] [ - ]CODE:
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”

5、一个更复杂的例子

下面我们将讨论一个更加复杂的expect脚本例子，这个脚本使用了一些更复杂的控制结构和很多复杂的交互过程。这个例子用来实现发送write命令给任意的用户，发送的消息来自于一个文件或者来自于键盘输入。

[Copy to clipboard] [ - ]CODE:
#!/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)的标准输出。

[Copy to clipboard] [ - ]CODE:
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后的程序块。

[Copy to clipboard] [ - ]CODE:
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号列表。

[Copy to clipboard] [ - ]CODE:
if {$nofile==0} {
setmesg [open "$file" "r"]
} else {
send_user “enter message,
ending with ^D: ” }
最后脚本根据变量nofile的值实现打开消息文件或者提示用户输入要发送的消息。

[Copy to clipboard] [ - ]CODE:
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进程。

tkpasswd: 这个脚本提供了修改用户密码的GUI工具，包括可以检查密码是否是基于字典模式。这个工具同时是一个学习expect和tk的好实例。

另附：

QUOTE:
创建时间：2001-04-29
文章属性：转载
文章来源：中国科大BBS站
文章提交：quack (quack_at_xfocus.org)

[版权声明]
　　
　　Copyright(c) 1999
　　　　
　　本教程由*葫芦娃*翻译，并做了适当的修改，可以自由的用于非商业目的。
　　但Redistribution时必须拷贝本[版权声明]。　　　　　　

[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 [llindex $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 [lindex $argv 1]
　　　　set password [lindex $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 [lindex $argv 1]
　　　　expect 　　　　eof　　　　　　　　　　　　{exit 1} 　　　　
　　　　　　　　timeout　　　　　　　　　　　　{exit 2}　　　　
　　　　　　　　”*No such user.*”　　　　{exit 3}　　　　
　　　　　　　　”*New password:”　　　　
　　　　send　”[lindex $argv 2 "
　　　　expect 　　　　eof　　　　　　　　　　　　{exit 4}　　　　
　　　　　　　　timeout　　　　　　　　　　　　{exit 2}　　　　
　　　　　　　　"*Password too long*"　　　　{exit 5}　　　　
　　　　　　　　"*Password too short*"　　　　{exit 5}　　　　
　　　　　　　　"*Retype ew password:"
　　　　send "[lindex $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　　　　[lindex $argv 1]
　　　　　　　　expect　”*Name*”
　　　　　　　　send　　　　　”anonymous ”
　　　　　　　　expect　”*Password:*”
　　　　　　　　send [exec whoami]
　　　　　　　　expect “*ok*ftp>*”
　　　　　　　　send “get [lindex $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 [lindex $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脚本可以驱动哪个调试器，设置好断点，执行该程序循环的若干步，然后将控制返回给键盘。它也可以在返回控制之前，在循环体和条件测试之间来回的切换。