Ожидайте, что скрипт работает много лет, ведет себя неожиданно с новой версией Expect

Question

Недавно я перешел с сервера FreeBSD 4.x на сервер FreeBSD 8.0. Теперь я использую expect-5.43.0_3. Я не помню, что такое старая версия ожидания, и я не могу быстро проверить, потому что жесткий диск на старой системе разбился в течение нескольких минут после завершения миграции ! (WHEW!)

В любом случае, у меня есть сценарий ожидания, который создает ZIP-файл tar и передает его по FTP каждую ночь. Этот сценарий успешно работает в течение ЛЕТ. Внезапно, с момента перехода/обновления, он работает некорректно, и я уставился на него и поиграл с ним для DAYS, не имея возможности его исправить. Я хочу, чтобы каждая команда FTP завершилась успешно, прежде чем перейти к следующему, поскольку следующие шаги включают удаление выбранных старых версий файла на удаленном сервере, и я не хочу делать DELETIONS, если TRANSFERS не работает правильно.

Так что - это часть сценария по-прежнему работает:

...

 
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" 

Обратите внимание, что в диалоговом потоке было «ЧЕРЕЗНО» «\ n226» перед «ftp>», но я последовательно получаю «непредвиденную подсказку ftp 2». Я попытался изменить его на «Перенос» или «Завершить», но он все равно имел тот же эффект. Прямо сейчас, я запускаю сценарий БЕЗ проверки на успешное завершение, но, я уверен, это меня не устраивает, и это несчастный случай, который должен произойти, поскольку следующие шаги удаляют выбранные старые файлы, которые я не хочу если эти файлы не были успешно перенесены, в те тесты, которые я сейчас НЕ ИМЕЮ.

Я предполагаю, что что-то изменилось с буферизацией/обработкой входного потока и что мне нужно изменить его так, чтобы он «видел» «\ n226» или «Перенос» или «завершен», прежде чем «видит» " ftp> ", но почему? И, если уж на то пошло, как? :)

Answer 1

Это может быть проблема с буферизацией и изменение порядка элементов в выражении ожидания может помочь.

Помните, что по умолчанию вы указываете шаблоны «glob» и что эти шаблоны сравниваются с буферами данных внутри Expect, а не строго по характеру по характеру. Предположим, что буфер произошло содержать этот фрагмент входного потока:

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

Это соответствует как шаблон Глоб «FTP>» и шаблон «\ N226» и с тех пор бывший появляется первый в ожидают утверждения, что действие будет быть казненным.