Hey,
Sorry to bother you guys again. We have been using development licenses for ever now and just now started trying out execution licenses. So when I’m in the terminal and execute the script, it acts like it’s working then it throws this. What does this mean?
kCGErrorIllegalArgument: CGSOrderWindowList
kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Then it just sits there, with a cursor. Have to Control-C to get the prompt back. I’ve looked around and I only see one other person with a similar issue, but it was never answered, way back in 2009.
just trying to execute script using “runscript” via the command line is all, our VNC is an adderlink as NO 3rd party software is allowed on the SUT.
Any ideas?
and I’m using this to connect to the adderlink:
Connect (serverID: “1.1.1.1”, portNum: “5900”, Visible: “No”)
IP is all ones for example…
Those messages are just warnings and can be ignored. It’s just a piece of the app that tries to do something with a graphics context that doesn’t exist because you don’t have a GUI, but it’s not a problem. The command line run won’t show anything until it either completes or fails, so it may not be hung, just running quietly. You could check that by looking in the Results directory of the suite to see if anything has been created by the run; if it has, you could then look at the output and see what it was doing.
How long does your script take to execute in the GUI? Have you waited at least that long for the command line to complete? What OS are you running eggPlant on and what version are you using?
Another suggestion is that while you are getting things setup consider using the flag
-CommandLineOutput YES
That will output all the detail to the terminal as your script runs.
…but now I think we are stuck at “helper” files via terminal. Our scripts aren’t seeing certain commands and ends right as it begins complaining about commands that can’t be found. I know the suiteinfo file stores this information, BUT everytime I try to populate the helper with my helper files, it copies it to a different file and labels it as corrupt. I’m fixing to create an suiteinfo on a developer machine and copy it over via USB and see if that fixes this. Is there a way to create the suiteinfo from terminal with an execution license, without it saying it’s corrupt?
You can edit those suiteInfo files by hand if you are careful about it, it’s just a text file. It’s probably best if you quote the paths to the helpers and make sure it’s in a valid form.
From the eggPlant Reference Guide:
You can change the path of a helper suite to make it relative to your Home directory or your Default Suite Directory. To start editing the path of the helper suite, select the helper suite in your Helpers pane and click in the path.
Paths that start with tilde (~/) are relative to your Home directory. Paths that start with a dot (./) are relative to your Default Suite Directory.
If you are running the execution as a different user (without access to the GUI preferences) you can specify the Default Suite Directory in a command line by adding this argument:
-DefaultDocumentDirectory path
ughhh, now I have a “suitelocking” problem, telling me to disable the suitelockingenable switch for eggplant, but this is an execution license, there is no eggplant gui, so when I try to do that it just pulls up the execution box with “Quit” and “Licenses”.
I’ve rebooted the machines and still have this issue, any ideas to why it’s having issues with suitelocking now?
[quote=“JonathanOSX”]You can edit those suiteInfo files by hand if you are careful about it, it’s just a text file. It’s probably best if you quote the paths to the helpers and make sure it’s in a valid form.
From the eggPlant Reference Guide:
You can change the path of a helper suite to make it relative to your Home directory or your Default Suite Directory. To start editing the path of the helper suite, select the helper suite in your Helpers pane and click in the path.
Paths that start with tilde (~/) are relative to your Home directory. Paths that start with a dot (./) are relative to your Default Suite Directory.
If you are running the execution as a different user (without access to the GUI preferences) you can specify the Default Suite Directory in a command line by adding this argument:
-DefaultDocumentDirectory path
[/quote]
I’ve been manually editing them, that’s when it was saying it was corrupt. I even pulled up one that had helpers already in there and copy and pasted them exactly and it still screamed it was corrupt. What am I doing wrong???
also what if I want to run multiple helpers from the command line, your example only specifies uses of one helper suite…is more than one possible?
I finally figured it out. You guys may want to update the manual with runscript info, cause half the stuff I did was not even mentioned in the manual. There is no “suiteinfo” file information in the manual/reference, the “locking” was not in the manual/reference, BUT it was mentioned being added in the Release Notes. Also all the information on runscript is very little. The information Jonathan gave me isn’t even in the manual/reference, so that there should say how little there is.
Just saying for the people using commandline, your manual/reference really doesn’t help them.
Thanks for the help Matt and Jonathan!
Thanks for the feedback.
There’s not usually any reason to do anything with the suiteinfo file. I don’t think I’ve ever had anyone doing that in order to run from the command line. One look at its format should tell you that it’s not intended to be edited by hand. Generally everything is set up under the GUI and if necessary, a couple of command-line flags take care of the rest of the configuration when moving to the command line. Most of the time the suites are copied to the execution machine with the same folder structure as that on the development box, and it’s just a matter of specifying the Default Suite Directory to get things running.
The locking issue occurs sometimes, but it’s not the norm, and the error message tells you how to resolve it – there’s nothing in the GUI that deals with it; it’s a command-line process. And I have no idea what this corruption issue is about; to my knowledge no one has ever reported it before, so I’m not able to tell you or document how to fix it.
I’m sorry that you had so many trials getting things working, but I’m glad to hear that you’ve overcome them.
The suiteinfo wasn’t copied over cause we never “check” that into our SCM as it was never needed before, with the GUI.
The locking, was when checked out, our files are “read” only. So to fix that I had to make them have “read & write” access.
The message it gives for fixing the suite locking did not work as it stated it was to be used with the eggplant command not runscript, which all it does is try to launch the GUI, which it fails, as this is an execution license. Also tried it with runscript, after runscript and after the script path. Did the same with “eggplant” command.
The info Jonathan gave me is not in the manual at all as a parameter. It does state something about a document directory when “opening suites” in the code. It also states it was located in general preferences. This wasn’t my issue though, but the fact that the parameter isn’t in the manual, leaves me to wonder what else didn’t make it in there.
Thanks, Joe.
We’ll get the -DefaultDocumentDirectory flag into the documentation in a future release.
The actual error message for the suite locking issue is:
"If your file system does not support file locking please use:defaults write Eggplant SuiteLockingEnabled NO"
I understand that it may not be completely clear that you need to execute that from the command line, but it’s the exact command that you need to run to turn off the suite locking. It’s not telling you to launch the GUI. I’ll suggest that the message be changed to something like:
"If your file system does not support file locking please run the following from the command line:defaults write Eggplant SuiteLockingEnabled NO"
I’ve deleted (so it can recreate itself), changed it to read and write, edited the owner, and the group, nothing is working. What am I doing wrong??
We just recently had to change the user names, so to keep the home folder we enabled root, logged in as root, renamed the folder, created a user the same as the home folder that we just renamed, it finds it, links it to the user we just created and then we reboot into the new user. Everything is fine, except when we run the script it screams about the suiteinfo file not being locked. Any other ideas before I run my head into a wall?
I don’t want to hear that it’s not possible to change the user and keep the home directory, obviously it’s possible. I just need the suiteinfo file to "lock’ or whatever needs to be done. I am open to suggestions.
How bad is it if it doesn’t lock? I know I can disable it as it says (actually still haven’t gotten that to work), but what advantage does it have to being locked vs unlocked?
hello?? anyone home? I have two questions now not being answered. Can I get some assistance somehow with them?
How bad is it if it doesn’t lock?
The locking mechanism protects the suite from simultaneous edits if multiple running eggPlant are working with the same copy of the suite at the same time. If that doesn’t happen in your configuration then it’s a non-issue.
Some cases where suite locking is important:[list]
[]The suite is on a shared drive and accessed by multiple users on different machines.
[]The suite is used by a GUI version of eggPlant and a Command Line version of eggPlant at the same time.
[*]The suite is on a server that has multiple users running eggPlant on it. (e.g. via Terminal Services).
[/list:u]
Also, the forums are great for discussions, and a good way to find answers to common situations. But if you have a priority support request it’s best to send that directly to our dedicated support address - support@testplant.com.
yeah, we don’t share suite’s or suiteinfo, everything is downloaded local via a distribution server of sorts. so I’m good?
Yes you should be. So go ahead and disable the locking as specified. In a terminal enter the command:
defaults write Eggplant SuiteLockingEnabled NO
On Windows it’s expected that you do that from inside the Eggplant folder in Program Files.