Handling Interactive Type Commands
|Top Previous Next|
Typically, the command sender type scripts (e.g, cisco_send_cmds, pix_send-cmds, generic_send_cmds, etc..) read in a list of commands to send to the device and send them one at a time. After each command is sent, the script is expecting to see a particular prompt string. However, there are some commands that are "interactive" where the default prompt string is not displayed, or some type of confirmation prompt is presented by the device. In some cases, the scripts all ready have built in functionality to support these interactive type commands on IOS devices (e.g., clear log ) and this feature is not needed. In other cases, the scripts do not have built in support to handle a particular interactive command. See the documentation page for each individual script for the built in, interactive, commands supported by each script.
For cases where there is not built in support for an interactive command, there is a special syntax in the command file which allows you to define a custom prompt for an individual command. Note, this feature is only available with the AutomaterPro License.
The syntax of the command is
<command> ::PROMPT "prompt"
where <command> is the command to send to the device and "prompt" is the prompt you are expecting to receive back from the device.
Going one step further you can even verify output for these types of commands using the additional CHECKFOR option (see example below)
<command> ::CHECKFOR "string" ::PROMPT "prompt"
Below is an example of manually saving a config to a cisco wireless LAN controller.
Below is the command file used to save the config of a cisco wireless LAN controller using the generic_send_cmds script. Note this is NOT and IOS type device, therefore we are using the generic_send_cmds script. Note, it is possible that this command file will not report a problem if the save config command failed.
If we want to confirm that the device responded with "Configuration Saved" before the prompt returned, the file would look like this. Note, we did not need the additional ::PROMPT feature on the second line because the prompt that is expected after entering "y", is the default prompt for this box.
if we wanted we could have also added the additional prompt keyword on the second line as follows: