0 votes
by (250 points)

I'm writing a program using Rebex Terminal Emulation to login to devices and automatically download the configuration files. The program makes extensive use of the scripting.DetectPromt() and scripting.ReadUntilPrompt() methods. I haven't had any problems with Cisco, Brocade and Palo Alto devices but with JunOS devices it has some strange behaviors. If I am in edit mode on these devices and issue a DetectPrompt it continuously cycles through that command until I hard quit the application, almost as if I was holding down the enter key. If I use the scripting.Prompt = ">" to manually tell it what prompt to expect and then issue a command such as "show configuration" followed by a "ReadUntilPrompt" it runs the command and then freezes because it never detects the prompt. It may have to do with the fact that the JunOS prompt is three lines long. An example is:

(blank line)

I think this is somehow confusing the control's ability to detect the prompt.

Has anyone else seen this behavior?

1 Answer

+1 vote
by (15.2k points)


yes, the three line prompt makes DetectPrompt() method unusable. It uses "common behaviour" of terminal servers that on empty line request prints the prompt (we are sending Enter key). Then we look to last 3 lines and try to find a matching line with the last one. This supports these scenarios:



(empty line)

In your case you have to use Prompt property as you tried, but with correct value. Please make sure that the ">" is last character of your prompt. It may be followed by space or white-space in general. You can try to set

scripting.Prompt = @"regex:>\s*";

which instruct the scripting class that you are using regular expression to describe the prompt and that the prompt should be ">" followed by zero or more white-spaces.

by (250 points)
Thanks! The regex did the trick. Apparently there is a white-space that was throwing it off.