How does "crt.Sleep" work?

[corp-mule]

How does "crt.Sleep" work? What triggers it?

It seems things in the script do not happen in the order that I put them ... into the script.

I want to ...

- Stop the current log file. Call this the "first log file."

- Start a "second log file" and save it in a different location.

- Run three commands and log the output into the "second log file" log file.

- Loop the third command until I stop it manually, logging the output into the "second log file."

- Stop the "second log file" log file.

- Then start a "thrid log file" (or continue the first one).

I put the "sleep" command *_AFTER_* three "show commands." But ... The script pauses after the first two "show commands," then it runs the third command.

Why does it pause after the "sh clock" command?

Why doesn't the "sleep" command pause **_AFTER_** the third command runs?

Also ...

When I stop the "second log file," ... some of the "show commands" get put into the 3rd log file.

Why don't the "sh clock" (and other commands) go into the "second log file" log file? Why do they end up in the 3rd log file?

The 3rd log file is started *_AFTER_* all the "sh commands" have been run.

#$language = "VBScript"
#$interface = "1.0"

crt.Screen.Synchronous = True

Sub Main

' If using a pre-configured session ...
'
If crt.Session.Logging Then
'
' Turn off logging before setting up our script's logging...
'
crt.Session.Log False
End If
'
' Set up the log file so that it resides in the path
' defined in the TEMP environment variable, and is
' named according to the remote IP address:
'
crt.Session.LogFileName = "I:\files\scripts\scrt-vbs-scripts\" & _
"!---test-%H--%M-%D--%h-%m.log"
crt.Session.LogUsingSessionOptions
'
' Send commands, etc.
'
        CRT.Screen.SendSpecial "MENU_CLEAR_SCREEN_AND_SCROLLBACK"
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "#"
	crt.Screen.Send "term len 0" & chr(13)
 	crt.Screen.WaitForString "#"
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "#"
	crt.Screen.Send "sh clock" & chr(13)
	crt.Screen.Send chr(13)
	crt.Screen.Send chr(13)
' 
' I want to run the next command at certain intervals, until
' I manually stop it.
' 
' I'd like to make it stop automatically after a specific
' period of time.  If that's possible, I'll have to figure it
' out later, I guess.
' 
' :: PROBLEM ::
' The following command does not run until the "sleep"
' command times out.
'
' Why doesn't the "sleep" command pause **_AFTER_** this
' command runs?
'
Do
	crt.Screen.WaitForString "#"
	crt.Screen.Send "sh ip cache flow | i ddress|0/0/3.334" & chr(13)
	crt.Screen.WaitForString "#"
        crt.Sleep 5000
	crt.Screen.Send chr(13)
	crt.Screen.Send chr(13)
Loop Until crt.Screen.WaitForKey(2)
	'crt.Screen.WaitForString "#"
	crt.Screen.Send "sh clock" & chr(13)
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "#"
	crt.Screen.Send "term len 24" & chr(13)
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "#"
'
' Turn off synchronous mode
crt.Screen.Synchronous = false
'
' Stop logging
'
' If using a pre-configured session ...
'
If crt.Session.Logging Then
'
' Turn off logging before setting up our script's logging...
'
crt.Session.Log False
End If
'
' Turn on logging;
'
' :: PROBLEM ::
' 
' The "sh clock" command above ends up in the second log
' file below.  Why?
'
' Why doesn't the "sh clock" (and other commands above) go
' into the first log file?
'
	crt.Screen.WaitForString "#"
	crt.Screen.Send chr(13)
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "#"
crt.Session.LogFileName = "I:\files\scripts\scrt-vbs-scripts\" & _
"%S--%M-%D--%h-%m.log"
crt.Session.LogUsingSessionOptions
crt.Screen.WaitForString "#", 5
crt.Sleep 5000
'
' Send more commands, etc.
'
End Sub

[jdev]

Sleep() isn't the problem. The absence of WaitForString "#" is the biggest obstacle to success for you right now.

Chapters 4 and 5 (especially section 4.3) of the Scripting Essentials: A Guide to Using VBScript in SecureCRT are great places to start for learning about sending and receiving data with SecureCRT scripts.

Several places within your script code, you're committing one of the most problematic SecureCRT scripting mistakes of all: You're calling crt.Screen.Send() multiple times in a row, without equivalent calls to crt.Screen.WaitForString().

Each and every time you call crt.Screen.Send() and your argument includes a chr(13) or a vbcr (simulating that you're pressing the Enter key), you should be performing a corresponding crt.Screen.WaitForString "#" in order to "synch up" the output from the remote to where you are in your script.

If you do this...

crt.Screen.Send "sh clock" & chr(13)
crt.Screen.Send chr(13)
crt.Screen.Send chr(13)

... then the first time through the Do...Loop later on, the call to WaitForString "#" is going to find the hash prompt associated with the earlier Send "sh clock" & chr(13).

You're then calling crt.Screen.Send "sh ip cache flow | "... too soon -- before you've waited for the last shell prompt to be received from the remote system.

You then call crt.Screen.WaitForString "#", but this only finds the "#" from the first of your empty Enter presses following the sh clock command earlier. Since data received will only get displayed to the terminal screen when a WaitForString (or other WaitFor* call is active), you won't even see the 'sh ip cache flow |...' command your Send() call made earlier.

You then have your script code Sleep for 5 seconds, followed by two more Send() calls, which put your script even more out of synch from where the remote is.

General rule: If you call Send(), follow it up with a WaitForString() to wait for what you'd expect to see as a result of the Send() call.

At first glance, one might suggest that another potential way to synchronize things would be to wait for the text of each command you "Send" to appear, for example:

strCmd = "term len 0"
crt.Screen.Send strCmd & chr(13)
crt.Screen.WaitForString strCmd
.
.
.
strCmd = "sh clock"
crt.Screen.Send strCmd & chr(13)
crt.Screen.WaitForString strCmd
.
.
.
strCmd = "sh ip cache flow | I ddress|0/0/3.334"
crt.Screen.Send strCmd & chr(13)
crt.Screen.WaitForString strCmd

This may be a good practice -- especially if you'd like to see the commands you Send() actually show up on the screen as they're sent to the remote (as opposed to after the commands have completed displaying their output) -- but even with this approach, data might still end up being dropped by the remote system because you're sending new commands before you know the remote is ready to receive anything new.

The sure-fire way to solve this problem is to implement the golden rule of SecureCRT scripting: Always pair up Send() with a corresponding WaitForString, WaitForStrings, or ReadString call.

If you sprinkle in healthy doses of WaitForString "#" calls after each Send() call you make, does your script begin to recover and work better for you?

[corp-mule]

jdev,

Yes! Thank you.

I added the WaitForString() after every send() and it resolved both of the problems.

Thank you for the explanation. I really appreciate it.

Corp-mule