run a sikuli script from Windows without clicking Run icon

Asked by Tintinux

Hi

I have created a small script, exported a .skl file and made a batch file containing :

java -jar %path_to_sikuli%\sikuli-script.jar" -r %path_to_skl%\exec.skl"

SikulixIDE 1.1.0 opens and shows the script, but do not run the script.

The Message window read :

[info] IDE startup: 6,5 seconds

When I click the "Run" icon, it runs as expected !

My question is : Is it possible to run without clicking the icon ?

Thanks

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
RaiMan
Solved:
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said :
#1

not possible, that you are talking about SikuliX 1.1.0.
sikuli-script.jar is from a version before 1.1.0

with 1.1.0 there is a
- runsikulix command file, that can be used according to

http://sikulix-2014.readthedocs.io/en/latest/faq/010-command-line.html#how-to-run-sikulix-from-command-line

Revision history for this message
Tintinux (tintinux) said :
#2

I'm talking about "SikulixIDE 1.1.0" as displayed in Help > Check update.

I have read previously the faq but did not understood what is expected.

I have tried :

1) with a shortcut to the cmd adding -r <filename>.skl in the target

     This displays briefly a "Dos" window and close it. Sikuli doesn't run. I can't read the message but it looks the same as below.

2) with another cmd file containing :

  start "Test" /b /d "%path_to_sikuli%" runsikulix.cmd -r %path_to_skl%\exec.skl

  It only displays (after the "pause" message) :

+++ running this Java
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
+++ trying to run SikuliX
+++ using: -Xms64M -Xmx512M -Dfile.encoding=UTF-8 -Dsikuli.FromCommandLine -jar D:\Users\esgjd\Documents\Perso\Sikulix\sikulix.jar -r D:\Users\esgjd\Documents\Perso\Sikulix\\sim.sikuli\exec.skl

Nothing runs even if the pause is not acknowledged..

This is why I tried eventually with the jar, as documented in an unofficial page, maybe obsolete, but which works a little better...

Any suggestion would be appreciated !

Regards

Revision history for this message
Best RaiMan (raimund-hocke) said :
#3

the folder containing the .skl should not be named .sikuli

... \sim.sikuli\exec.skl

Revision history for this message
Tintinux (tintinux) said :
#4

Ok, it works when I move the .skl file somewhere else !

However if find the requirement a little weird and usually I put everything about a project in the same folder...

Thanks

Revision history for this message
Tintinux (tintinux) said :
#5

Thanks RaiMan, that solved my question.

Revision history for this message
RaiMan (raimund-hocke) said :
#6

--- However if find the requirement a little weird and usually I put everything about a project in the same folder...
Sorry for the inconvenience, but
- a .sikuli folder is something like a package (which cannot be guarded like on Mac) containing code and resources and should not contain any other user content, that is not managed by SikuliX
- the ending .sikuli signals, that it is a sikuli script folder, that can be opened in the IDE and run from commandline

Hence you should look at a .sikuli folder as an entity like a file.

Your requirement, to put anything together in one folder is not touched by this SikuliX convention, if you use the folder containing the script(s) as your container folder.
Such an organization is well supported by SikuliX.

SikuliX version 2 will use other container formats (jar, zip, ...)

Revision history for this message
NounouRs (sandburg) said :
#7

On this topic, the documentation says few.
https://sikulix.github.io/docs/scripts/running-scripts/

> You can run scripts by simply clicking run from the IDE or using the command line to run saved scripts (.sikuli) and exported scripts (.skl and .jar).

So for the second part "using the command line to run exported scripts .jar. ", maybe an example should be added.

Because, I think most of us would think to do:
 java -jar my_exported_script.jar

Which, ha ha, doesn't work.