Как обрабатывать «двойные» промпты с помощью инструментов типа expect?
В своей работе используем перловый модуль Net::Telnet для написания "драйверов" для сетевого оборудования. Сложился довольно обширный опыт по общению с оборудованием, но вот одна задача не дает покоя.
Итак, предположим, что мы автоматизируем "общение" с неким сетевым оборудованием используя некий инструмент, похожий на expect. Суть инструмента заключается в отправке команд на оборудование и анализе ответа. Т.к. в большинстве случаев используются протоколы типа Telnet или TL1, то признаком завершения ответа оборудования является prompt.
Все отлично автоматизируется, когда оборудование после ответа на каждую команду возвращает один единственный, легко описываемый регулярным выражением promt. Но вот есть оборудование, которое на некую команду (например, просмотр статуса порта) возвращает ответ следующим образом:
Вариант 1 - порт активен
<статус порта>
prompt#
<параметры порта>
prompt#
Вариант 2 - порт не активен
<статус порта>
prompt#
Т.е. в зависимости от неких параметров, ответ оборудования на команду может содержать не один prompt. Это может зависеть от: версии прошивки, вида команды, результатов команды.
Вопрос: может кто сталкивался или имеет хорошие идеи, как более-менее универсально можно обработать такую ситуацию?
На текущий момент имеем такое решение (от которого и хочется отказаться):
заранее определяем, какие команды могут получить "двойной" prompt и именно для них принудительно ждем тот второй prompt. Большой минус этого способа - при этом не анализируется версия прошивки. Из-за этого на части оборудования получаются потери времени на ожидание второго prompt, который отсутствует на определенной прошивке. Проанализировать весь спектр прошивок - задача, конечно, решаемая, но очень трудоемкая. Да еще не всегда можно отследить появление новой прошивки.
buffer - scalar reference to object's input buffer $ref = $obj->buffer;
This method returns a scalar reference to the input buffer for $obj. Data in the input buffer is data that has been read from the remote side but has yet to be read by the user. Modifications to the input buffer are returned by a subsequent read.
Если не пустой - значит после промта еще есть данные и надо ждать второго промта.
можно, но непонятно сколько времени ждать, пока в буфере что-то должно появится?
Пока видится такой вариант: все-таки привязка остается к конкретной команде, но теперь для нее не принудительно ждем второй prompt, а только если c первым prompt придет необходимая строка. Т.е. исходя из указанного примера: если видим, что порт активен - ждем второй prompt.
