Linux怎么使用expect脚本_Linux如何自动化交互式命令【技巧】

写expect脚本这事儿，很多人以为就是按格式填几个命令，结果一跑就傻眼——要么启动就报错，要么卡在某个地方不动，要么命令发出去石沉大海。其实，expect脚本不是魔法，它只是个忠实的执行者，你让它等什么、发什么，它就照做。问题往往出在，你告诉它的“剧本”，和实际终端里上演的“剧情”对不上。

expect 脚本执行前必须确认的三件事

脚本跑不起来，第一步先别怀疑逻辑，检查下面这三项基础配置，缺一不可：

首先，系统里得有expect。敲个which expect，它得返回一个像/usr/bin/expect这样的路径才行。如果没有，那就得先安装，CentOS系用yum install expect，Debian/Ubuntu系用apt-get install expect。

其次，底层依赖tcl也得在。通常安装expect时会自动带上，但如果运行时报错can't find package Tcl，那就得手动补上：yum install tcl。

最后，脚本文件本身得“合规”。首行必须是#!/usr/bin/expect，注意这里最好用绝对路径，有些系统对#!/usr/bin/env expect这种写法不买账。写完别忘了用chmod +x your_script.exp给它加上执行权限。

spawn 启动命令后，expect 匹配不到提示符的常见原因

脚本启动了，但卡在第一个expect语句上不动弹，这是最常见的问题。原因多半不是正则表达式写错了，而是你预想的输出和程序实际吐出来的内容压根不是一回事。

举个典型例子：你用spawn ssh user@host，脑子里想的是它直接出password:。但实际上，它可能先冒出一行The authenticity of host 'xxx' can't be verified.问你yes/no，然后才是密码提示。如果你的脚本只写了expect "password:"，那它就会死死等在那句“yes/no”上，永远等不到“password:”。

怎么破？首先，别猜，用事实说话。运行脚本时加上-d调试参数：expect -d ./script.exp。这时你会看到expect实际捕获到的每一个字符，包括那些看不见的控制符，真相一目了然。

其次，匹配策略要灵活。别只用字符串完全匹配，用-re启用正则表达式，一次覆盖多种可能。比如：expect -re "(password:|yes/no|.*\$)"，这样不管先来密码提示还是主机认证提示，都能接住。

另外，注意细节。提示符末尾可能有空格或制表符，用.*兜底更稳妥：expect "password:.*"。远程登录后的shell提示符更是千变万化，可能是[root@host ~]#，也可能是user@host:~$，别硬写expect "$ "，用个宽泛的正则如expect -re {[.*]|.*$}会更可靠。

send 发送密码后脚本立刻退出，而不是继续执行命令

另一个让人头疼的场景是：密码发出去了，脚本也立刻结束了，你期望它执行的后续命令（比如ls）根本没跑。问题出在哪？

核心在于误解了send和expect的协作关系。send只负责“发送”，它不管对方“收到没”或者“准备好没”。你发完密码，紧接着就send "ls"，但此时远程shell可能还在处理登录流程，根本没到能接收命令的状态，这个ls命令就被无声无息地丢弃了。

所以，黄金法则是：每次send之后，必须跟一个expect来等待下一个明确的提示信号。 发完密码，得等出现shell提示符（如expect "# "或expect -re {\$|#}）后，再发送下一条命令。

还有两个细节别忽略：一是send命令别忘了在末尾加\r（回车），send "ls\r"才是执行，光send "ls"只是把字符敲到终端里，没按回车。二是脚本的收尾，如果想执行完命令后把控制权交还给用户手动操作，就在脚本末尾加interact；如果只想安静地执行完然后退出，就用expect eof。

最后提个安全建议：别把密码明文写在脚本里。可以用set password $env(PASSWD)从环境变量读取，运行的时候这样调用：PASSWD=your_password ./login.exp。

timeout 设为 -1 并不安全，真实场景要分层设值

很多人图省事，在脚本开头写一句set timeout -1，意思是永不超时。这看似一劳永逸，实则埋下大坑。

想象一下，远程主机宕机了，或者网络突然断了，你的脚本就会永远挂在那里等待一个永远不会到来的响应。在自动化流水线（CI/CD）里，这意味着任务卡死，资源占用，需要人工介入才能终止。

正确的做法是根据不同操作阶段的合理耗时，分层设置超时时间：

• 连接阶段（如spawn ssh）：网络连接和初始握手，10到15秒通常足够。 set timeout 15
• 认证阶段（等待密码提示符）：输入密码后等待shell准备就绪，5到8秒足矣。
• 命令执行阶段：这完全取决于你发的是什么命令。一个ls可能只要1秒，但一个rsync大文件传输可能需要设120秒，一个apt update可能需要300秒。这里需要根据实际情况预估。

更重要的是，每一个expect语句块，都应该包含对timeout情况的处理。例如：

expect {
    timeout { send_user "SSH连接失败，超时！\n"; exit 1 }
    "password:" { send "$passwd\r" }
}

这样，一旦在预定时间内没等到预期响应，脚本就能优雅地报错退出，而不是无限期挂起。

说到底，用好expect的关键，不在于死记硬背它的语法，而在于你得真正理解你要自动化的那个交互过程：目标程序到底会输出什么（包括那些隐藏的控制字符）、它输出的顺序是怎样的、中间会不会插入无关的系统日志、终端环境会不会影响输出（比如颜色代码）。只有摸清了这些，你写出的expect脚本才能精准可靠，而不是一个碰运气才能跑通的“玄学”脚本。