View Single Post
Old 10-26-2016, 02:12 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 1,070
Seems like there would be a lot of overhead in just creating the .csv file...

How are you generating that CSV file to begin with?

If it's a manual operation, it seems like it might be just as effective to create individual sessions in sub-folders (each named to match your group numbers) that you can then edit to perform Logon Actions to issue the commands you want to run. Then, you can connect to sessions within each folder in a new window by right-clicking the folder and choosing "Connect in Tabs in New Window".

If you desire to script this, it would possibly be fraught with complication and reliability issues since you desire to have a separate window for each group and each connection is running a separate command. Passing a "command" to run at the remote shell (once it's ready) would involve using /SCRIPT "path/to/SomeRunCommand.vbs" /ARG "command you desire to run", but since /ARG is global to SecureCRT across all existing tabs in that instance, you'd have to play with timing to make sure the first tab's RunCommand.vbs script has an opportunity to read the crt.Arguments() before the subsequent tab gets launched with its /ARG value overwriting what was originally available in that window.

You'd probably need to split it up into a master script and subscript. The master script would operate outside of SecureCRT, reading the CSV file and launches separate instances of SecureCRT for each "group". The subscript would be something the master script kicks off when launching SecureCRT, using the /SCRIPT command line argument to tell SecureCRT to start running a script once connected. The subscript would be passed in an arg informing SecureCRT as to what command to run once it's safe to start sending things to the remote device. Your master script would need to introduce delays between each launching of SecureCRT so that prior instances have an opportunity to process the /SCRIPT file and read in any /ARG values to stash into variables before the next SecureCRT gets launched.

Launching the first instance of SecureCRT for a "group" would need to be done without /T, and subsequent launches of SecureCRT for the same group would need to be with /T.

Also, the first launch of SecureCRT for a group would need to be followed by enough of a delay to allow that first instance to get up and running, prepared to handle the /T hand-offs that will be coming its way for the subsequent launchings of SecureCRT for subsequent hosts/commands part of the same group.

Don't have an example of this yet, but if something becomes available, we can try to revisit this.

The forum community is welcome to chime in with any ideas/examples they have already available...

Jake Devenport
VanDyke Software
Technical Support
YouTube Channel:

Last edited by jdev; 10-26-2016 at 05:19 PM.
Reply With Quote