View Single Post
Old 05-15-2013, 05:01 PM
miked's Avatar
miked miked is offline
Registered User
Join Date: Feb 2004
Posts: 2,039
I'd call these 'session config files' and not 'sessions'... right?
In SecureCRT and SecureFX the items you see in the Connect window are referred to as sessions. Sessions are saved as .ini files (that your boss gave you, and which are stored in a folder named Sessions inside the configuration folder). If we were talking about TCP/IP packet analysis, or the OSI model, then session could take on other meanings, but there's not much reason to talk about things at that level on the VanDyke forums.

Thank you for providing more details. I think there are several different ways you could solve the problem effectively. Here's one possible path:

The SecureCRT Script Recorder is an easy way to generate all of the scripts for the different devices (see section 1.2 of the SecureCRT Scripting Guide). Connect to the device, start the Script Recorder, issue some commands, then stop the Script Recorder. This will provide the WaitForString/Send that you need for a particular type of device, and help avoid any common mistakes, like having back to back crt.Screen.Send calls without a crt.Screen.WaitForString call in between.

Once you have that script, you may be ready to expand it a little to accommodate different types of devices... If based on the response to a particular command you can determine the device type, and thus the specific command to send (show ip interface brief vs. show interface brief). You could use crt.Screen.WaitForStrings (plural) to list the various possible responses to the one command that tells you what kind of device it is. Based on the response, you might choose to call a function, or maybe just set the get interface command in a Select Case statement.

That's the path that seems fastest to me.
VanDyke Software
Technical Support
Reply With Quote