View Single Post
Old 10-21-2015, 12:58 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 1,099
Before going too far down a diagnostic approach, you made a statement that I can interpret different ways, so I thought I'd ask for clarification:

> Here is a cut-down version of the script I'm using the
> exhibits the behaviour I'm describing:

Does this cut-down version exhibit the problem?

In other words, if you're already connected with SecureCRT to your jump host, and you're sitting there at the jump host's shell prompt and you run this cut-down script, do you see the problem occur?

BTW, the 'ssh' and 'telnet' you're sending as commands to your jump host should not be considered as relevant to SecureCRT's synchronous property... the only protocol that matters to SecureCRT is the initial protocol you use in SecureCRT's session configuration to connect to your jump host. After that, anything you do is simply text being sent to the remote, and text appearing on the screen to SecureCRT. This means that the 'ssh' and 'telnet' commands you're running in the remote shell don't have much to do at all with SecureCRT's "synchronous" attribute. Once Synchronous is set to true on the SecureCRT Screen object, it remains true until SecureCRT itself is disconnected, or until your script stops running, or until you set Synchronous back to True with a line of code).

If in your script you're running a loop issuing 'telnet' and 'ssh' commands on your jump host to multiple hosts, you will want to make sure that you perform a WaitFor...() operation on ALL commands you send (even the 'exit' at the end). Otherwise, things could get out of sync.

The way to handle this specifically is to know what the prompt will always be for your jump host, and set that as a special one that you wait for after each "exit" command you use to "disconnect" the jump host from the secondary host.

Another possibility is that the remote system might be sending an escape sequence that contains text that could be found that doesn't appear on the screen. For example, some UNIX shell prompts include escape sequences that set the "title" of the window; such titles can include the prompt text, which can result in WaitForString*() returning unexpectedly. You can set Screen.IgnoreEscape = True, to make sure that escape sequences don't cause problems with your WaitFor()s.

To have an idea of what's actually being sent to SecureCRT, you can turn on "Raw" logging (File -> Raw Log Session), run your script, and then go take a look at the raw log file to see what the remote is sending to SecureCRT (some of which doesn't get displayed to the terminal screen because it's part of an escape sequence).

Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: