How to handle "double" prompts with tools like expect?

Question

Perl

In our work, we use the Net::Telnet pearl module to write "drivers" for network equipment. There was a fairly extensive experience in communicating with the equipment, but one task haunts.
So let's say we automate "talking" to some network equipment using some tool similar to expect. The essence of the tool is to send commands to the equipment and analyze the response. Because in most cases, protocols such as Telnet or TL1 are used, then prompt is the sign of the completion of the equipment response.
Everything is perfectly automated when the equipment, after responding to each command, returns one single one, easily described by the regular expression promt. But there is equipment that returns a response to a certain command (for example, viewing the port status) as follows:
Option 1 - the port is active
<port status>
prompt#
<port parameters>
prompt#
Option 2 - the port is not active
<port status>
prompt#
Those. depending on some parameters, the response of the equipment to the command may contain more than one prompt. It may depend on: firmware version, command type, command results.
Question: can anyone come across or have good ideas how to more or less universally handle such a situation?
At the moment, we have such a solution (which we want to refuse): we
determine in advance which commands can receive a "double" prompt and it is for them that we forcibly wait for that second prompt. The big disadvantage of this method is that the firmware version is not analyzed. Because of this, some parts of the equipment lose time waiting for the second prompt, which is not available on a certain firmware. To analyze the entire range of firmware is, of course, a solvable task, but very laborious. Moreover, it is not always possible to track the appearance of a new firmware.

Answer 1

You can try parsing buffer:
buffer - scalar reference to object's input 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.
If it is not empty, then after the prompt there is still data and you have to wait for the second prompt.