Expect脚本配置APC PDU时长命令卡顿需手动交互的问题咨询

从调试输出可直接定位核心问题：

• 脚本错误使用interact -o 作为等待逻辑。interact 的设计是打通本地键盘和远程会话的双向透传，仅当匹配到目标字符串时才退回脚本控制。发送长命令时，APC PDU的SSH终端会把回显拆成多个TCP分片返回，透传模式下的匹配逻辑会错位，最终卡在等待本地键盘输入的状态——这就是为什么必须手动按回车脚本才能继续。
• 调试日志里明确显示，本该完整发送的olStatus machine-123456\r 被拆成了olStatus machine-123 和456\r 两段，中间还插入了本地终端自动发出的回车，这是interact 透传本地终端行缓冲规则、未开启raw模式导致的命令截断。

1. 全部移除脚本中的interact -o 逻辑，改用Expect原生的expect 命令做流式匹配，彻底取消双向透传，从根源上避免进入等待键盘输入的状态。
2. 关闭SSH主机密钥检查的交互提示，避免额外的超时阻塞流程。
3. 针对APC PDU输出可能出现的重复提示符、空行场景，使用宽松正则匹配提示符，避免回显分片导致的匹配失败。

#!/usr/bin/expect -f
set timeout 10
log_user 1

# 建立SSH连接，跳过主机密钥校验
spawn ssh -o StrictHostKeyChecking=no $user@$pdu

# 等待密码输入提示
expect {
    "assword:" {
        send "$password\r"
    }
    timeout {
        puts "连接PDU超时"
        exit 1
    }
}

# 等待进入命令行提示符
expect "apc>"

# 发送状态查询命令
send "olStatus $host\r"

# 等待命令执行完成，兼容空行、重复提示符场景
expect {
    -re "apc> *\r?$" {
        puts "命令执行完成"
    }
    timeout {
        puts "命令执行超时"
        exit 1
    }
}

• 如果长命令仍存在截断、匹配错位问题，可在send 命令后增加200ms短延迟（sleep 0.2），给设备命令行缓冲区留足时间接收完整输入，再启动提示符匹配。
• 用于程序自动调用的脚本不要混用interact 命令，仅在需要临时让用户手动操作的场景使用，否则会大概率出现流程阻塞。

内容的提问来源于stack exchange，提问作者Nina