I believe the way you tackle this problem is using scriptSet/scriptGet. That's how I pass variable between the iTest and TCL shells. This is the gateway command that passes information between these two interfaces. This is how I would tackle this problem.
If you set a = 1 in iTest a = 2 in tcl shell you will get 1 and 2 respectively if you do a puts in either shell.
Wrap your work into a QuickCall and you should be good. I think John had it figured out with the scriptSet but may have had some garbage in the path.
Also, if you want to clean up the output from a stored response use this command [response varName]. I use that method all the time because I can tell it's a variable from a stored response.
Example testcase:
passdatabetweenitestantclshells.fftc
The problem I have with all this is that there is no way to control or predict if TCL or JACL will be used even when I have the preferences set to use TCL.
only problem is that every type of iTest step does not support directing what TCL interpreter to use. I can't force the "eval" command to use the JACL or TCL 8.4 or TCL 8.5 interpreters.
You're correct. Basically, do all your calculations in the iTest interpreter context and when you want to send data, use the ScriptSet action. Or, pass in your data using ScriptSet and then do your processing in the tclsh session.
@amichaels I don't understand why JACL is still running. The uriToPath should not be working at all with TCL 8.4. We can do a webex now it you lilke.
Hmmm... I still can't replicate the situation you're seeing, where you have what appears to be the full structured data of the response. I've run this on multiple machines, different versions of iTest and even different platforms. At this point, barring a webex, I'd take @gretztx's recommendation and strip out the first item of the list in the response.
one problem is that I have TCL 8.4 selected in my preferences, JACL is still running.
- @bondo, a quick and dirty "fix" would be to add this line right after the uriToPath command
- eval set path [lindex $path 0]
The lindex command isn't escaping the backslashes. It's removing all the other list items from the response so that you only have 1 instance of the path.
Oh, that makes sense. I still do not understand why I get all that extra stuff that you do not.
Well, I'd be happy to hop on a webex to check it out on your environment if you're interested. That is bizarre.
Yes, that machine is acting weird. Can you run that testcase on another VM? I'm betting it will work. As mentioned in our conversation, this is best followed up with support. I'm guessing they'll recommend a re-install of iTest 5.1, but I'll leave it to them. Good luck!
What are your Tcl interpreter Prefs?
52 People are following this question.
