Скрипт Expect, работающий годами, неожиданно ведет себя с новой версией Expect - PullRequest
Новая
       10

Скрипт Expect, работающий годами, неожиданно ведет себя с новой версией Expect

1 голос
/ 03 марта 2010

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

В любом случае, у меня есть сценарий ожидающего создания, который создает заархивированный tar-файл и передает его по FTP каждую ночь. Этот скрипт был успешно запущен в течение многих лет. Внезапно, после миграции / обновления, она работает неправильно, и я смотрел на нее и возился с ней в течение ДНЕЙ, не имея возможности это исправить. Я хочу убедиться, что каждая команда 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 > Строка, но почему? И, если на то пошло, как? :)

1 Ответ

0 голосов
/ 01 апреля 2010

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

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

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

Это соответствует как шаблону глобуса "ftp>", так и шаблону "\ n226", и, поскольку первый появляется первым в операторе ожидания, действие будет выполнено.

...