Question

我最近从FreeBSD 4.x服务器迁移到FreeBSD 8.0服务器。我现在正在使用expect-5.43.0_3。我不记得旧版本的预期是什么，我无法快速检查，因为旧系统上的硬盘在完成后几分钟就崩溃了移民！（呼！）

无论如何，我有一个期望脚本，它创建一个压缩的tar文件并每晚通过FTP传输它。此脚本已成功运行YEARS。突然之间，自从迁移/升级以来，它无法正常工作，而且我已经盯着它并且在没有能够解决它的情况下摆弄DAYS。我想确保每个FTP命令都已成功完成，然后再转到下一个，因为接下来的步骤包括删除远程服务器上文件的所选旧版本，如果TRANSFERS是，我不想做DELETIONS不正常。

所以 - 脚本的这一部分仍然有效：

...

spawn ftp $ftpmode $ftphost
expect timeout {puts "\nftp connection timeout(implicit)\n"; exit 3}
"timed out" {puts "\nftp connection timeout(explicit)\n"; exit 3} 530 {puts "Login failure!"; exit 3 } "\n230"
expect timeout {puts "\nftp command prompt timeout before progress command\n"; exit 8} "ftp> "
send "progress off\r"
expect timeout {puts "\nftp command prompt timeout before hash command \n"; exit 9} "ftp> "
send "hash 32768\r"
expect timeout {puts "\nftp command timeout";exit 5} "ftp> "

# For each archive file we find (this will catch us up if we've
# been unable to transmit for a few days), send and delete
foreach archive [glob -nocomplain ${archivestem}*$archiveext] {
    send "put $archive\r"
    expect "ftp> " {puts "ftp unexpected prompt 1"; exit 3} timeout {puts "ftp put timeout\n";exit 3} "\n150"

... 这是对应于执行的对话流以上：

230 User XXXXXXX logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> progress off
Progress bar off.
ftp> hash 32768
Hash mark printing on (32768 bytes/hash mark).
ftp> put crewsched-alldump-2010-02-27.tgz
local: crewsched-alldump-2010-02-27.tgz remote: crewsched-
alldump-2010-02-27.tgz
227 Entering Passive Mode (141,224,159,31,30,167)
150 Opening BINARY mode data connection for .
#####################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
226 Transfer complete.
21689518 bytes sent in 01:15 (280.27 KB/s)

（注意 - 哈希标记允许我快速使用低超时值检测脚本是否挂起）

到目前为止，真好！一切仍然以最后的方式运作六年，但下一行失败，“ftp意外提示2”，即使它正在寻找的字符串，“\ n226”是明确的对话流

    expect \# exp_continue "ftp> " {puts "ftp unexpected prompt 2"; exit 3} timeout {puts "ftp put timeout\n";exit 3} "\n226"

请注意，在“ftp＆gt;”之前，对话流中有一个非常清晰的“\ n226”，但我始终得到“ftp意外提示2”。我尝试将其更改为“转移”或“完成”，但它仍然具有相同的效果。现在，我正在运行脚本而没有检查是否成功完成，但显然，我对此并不满意，并且这是一个等待发生的事故，因为以下步骤删除了选定的旧文件，如果这些文件未成功传输我不想这样做，我目前没有这个测试。

我认为输入流缓冲/处理时出现了一些变化，我需要更改它以便在“看到”“ftp＆gt”之前“看到”“\ n226”或“传输”或“完成” ;“字符串，但为什么？而且，就此而言，怎么样？：）

Answer 1

这可能是一个缓冲问题，更改expect语句中项目的顺序可能会有所帮助。

请记住，默认情况下，您指定“glob”模式，并将这些模式与Expect内部的数据缓冲区进行比较，而不是严格按字符进行比较。假设缓冲区恰好包含输入流的这个片段：

######
226 Transfer complete.
21689518 bytes sent in 01:15 (280.27 KB/s)
ftp>

这匹配glob模式“ftp＆gt;”和模式“\ n226”，因为前者在expect语句中首先出现将执行操作。

多年来工作的Expect脚本在新的Expect版本中出乎意料地表现出来

1 个答案: