Forum Discussion
Perhaps I should explain what these lines do:
/*This logs into the device. Once logon happens, the script can send text to the device and the device can send text back to the script. Any text sent back and forth will be stored in cli.stdout().*/ cli=Expect.open(host, user, pass); /*This sleeps for 10 seconds. The purpose of this is to give your device time to send your script something now that it's logged on. This can include a message of the day, logon banner, etc., but also includes (hopefully eventually) a prompt: some text indicating that the device is ready to receive a command from the script.*/ sleep(10000) /*When expect runs, it is constantly listening to the device to see if anything comes in. This line prints out the contents of cli.before(), which is the holding place for any text received before the most recent expect match...*/ println(cli.before()) /* This is an expect match. This tells the script to look for a # sign in the text streaming from the device. Usually, this is used to signal to the script that the device is ready to receive commands. It's ready to receive commands because the device sent back the prompt which is usually like "my-cisco-ice#" When the script sees the # sign in the text coming from the device, it takes everything before that pound sign and puts it into cli.before()*/ cli.expect("#");
In each of your attempts, you had cli.expect("#"). It would seem that the prompt for this device doesn't contain the pound sign so the script isn't not finding it. The script is waiting for a prompt with a # in it, but the device doesn't use the # sign (or it doesn't in the current mode) in its prompt. Because the script never finds it, the script exits with a non-zero exit code. When testing a script from the UI, a non-zero exit code doesn't actually display the output. In order to get that, you'll need to go into the collector console and issue a !groovy command. This will give you a dialog box where you can pick a device and run a groovy script. Then it'll give you the whole output.
I'm doing this against a linux box. The prompt is like this. I found this out simply by manually logging into the device and looking at what the prompt was. Notice that mine does not contain a #. If my script is expecting the device to send a #, the script will timeout waiting for something that will never get sent.
[sweenig@staticcollector ~]$
So, i've setup my expect statements to be slightly different. I had to create a regex expression to match on the prompt. I used https://www.regexpal.com/ to make sure my expression caught the whole thing and nothing else from my manual session.
I ran this script against one of my linux devices (centos).
import com.santaba.agent.groovyapi.expect.Expect host = hostProps.get("system.hostname") user = hostProps.get("ssh.user") pass = hostProps.get("ssh.pass") prompt = /\[.+\]\$\s/ //this is the regex that identifies my prompt "[sweenig@staticcollector ~]$ " cli=Expect.open(host, user, pass) //connect cli.expect(prompt) //Waiting for prompt... cli.send("ls -l ~ \n") //Issuing command cli.expect(prompt) //Waiting for prompt... println("Full Output:\n" + "="*60) println(cli.stdout()) println("="*60) println("Just the output between the prompts:\n" + "="*60) println(cli.before()) println("="*60) return 0
This is what the output looks like:
returns 0 output: Full Output: ============================================================ Last login: Mon Aug 31 17:07:19 2020 from localhost [sweenig@staticcollector ~]$ ls -l ~ total 278764 -rwxrwxr-x. 1 sweenig sweenig 23284 Mar 25 04:15 LogicmonitorBootstrap64_6.bin -rwxr-xr-x. 1 root root 285427235 Mar 25 04:17 LogicmonitorSetup.bin [sweenig@staticcollector ~]$ ============================================================ Just the output between the prompts: ============================================================ ls -l ~ total 278764 -rwxrwxr-x. 1 sweenig sweenig 23284 Mar 25 04:15 LogicmonitorBootstrap64_6.bin -rwxr-xr-x. 1 root root 285427235 Mar 25 04:17 LogicmonitorSetup.bin ============================================================
The key is that my cli.expect statements were looking for a prompt that actually exists in the text returned by the device.
Related Content
- 2 years ago
- 3 months ago
- 2 years ago