Command line

Hi everyone.

I’m having some trouble getting superlab to run from the command line. I can get the superlab experiment file to run but it just sits on the editor screen and wont run.

Here are my command line arguments (using macOSX10.7.3)

open experiment.sl4 --args – nosplash -r -q -e experiment.sl4 -o savefile -n participant -g groupName

I’m not sure if the argument for the group argument is correct the rest seem ok to me. What do you guys think I’m doing wrong?

Thanks

Hi SCL,

I would bypass the ‘open’ command. Instead, directly call the SuperLab binary from the command line, and pass the arguments directly to SuperLab.

Here is how:

/Applications/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5 --nosplash -r -q -e “/full/absolute/path/to/experiment.sl4” -o “/full/absolute/path/to/savefile” -n participant -g “Main Group”

Also, there should be no whitespace between the double-hypen and ‘nosplash’. It is ‘–nosplash’ instead of ‘-- nosplash’.

I just tested this on 10.7.3 and it works as expected.

Hope that helps,
Kelly

Thanks Kelly,

Your solution works except on my system Superlab is located in:

/Applications/SuperLab\ 4.5/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5
not
/Applications/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5
as you had it.

It looks like what I was doing wrong before was opening SuperLab from the experiment file:

./experiment.sl4 --nosplash -r -q -e “/full/absolute/path/to/experiment.sl4” -o “/full/absolute/path/to/savefile” -n participant -g “Main Group”

Hmm I’m still having issues and maybe this problem is less to do with SuperLab and more to do with my lack of understanding the command line or shell scripts.

When I try to run superlab from the command line or from a shell script the terminal retains focus and I can’t proceed with the Superlab experiment.

Any suggestions on how to hide the terminal or focus superlab?

Thanks

Hi SCL,

I have not encountered the problem that you describe (with Terminal remaining in the foreground).

Nonetheless, I found the following ‘osascript’ command via an online search, and this indeed seems to hide the Terminal window.

I recommend that you first try this command by itself to see if it indeed does hide the window:

osascript -e ‘tell application “System Events”’ -e ‘set visible of process “Terminal” to false’ -e ‘end tell’

I noticed that it had a several second lag the first time that I ran it. But during subsequent tests of the command it would hide the window almost instantaneously. My guess is that the first run caused a bunch of the AppleScript environment to be loaded into memory for the first time.

If that command works, then you would combine it with the SuperLab command using an ampersand, like so:

/Applications/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5 --nosplash -r -q -e “/full/absolute/path/to/experiment.sl4” -o “/full/absolute/path/to/savefile” -n participant -g “Main Group” & osascript -e ‘tell application “System Events”’ -e ‘set visible of process “Terminal” to false’ -e ‘end tell’

That should launch SuperLab and immediately hide the Terminal window.

Ki Kelly,

Thank you for your reply, the osascript does what you say however I now believe the problem is due to SuperLab being passed something it doesn’t like. Even with the terminal in the back ground SuperLab wont take focus.

Here is the error message I receive in the terminal when trying to open SuperLab from the command line.

2012-05-15 10:58:51.970 SuperLab 4.5[23076:2203] CFURLCreateWithString was passed this invalid URL string: ‘/System/Library/CoreServices/CommonCocoaPanels.bundle’ (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.

Edit: I just found out that I can hit return in response to the terminal message and superlab takes the focus and works fine. The problem is I am using a script to run several studies in a row and I don’t have an experimenter available to hit return every time this happens. Any thoughts?

Thanks

Hmmmm…

Does it work if you reverse the order of the osascript command and the SuperLab command?

Like so:

osascript -e ‘tell application “System Events”’ -e ‘set visible of process “Terminal” to false’ -e ‘end tell’ & /Applications/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5 --nosplash -r -q -e “/full/absolute/path/to/experiment.sl4” -o “/full/absolute/path/to/savefile” -n participant -g “Main Group”

Yes the problem persists if I switch the order around. The issue seems to be independent of the osascript. My impression is that superlab doesn’t want to proceed because it hits an error. Note the error occurs independent of whether the osascript is run or not.

Any other ideas?

Thanks

Well this is a problem. Another reason to implement the ability to combine 2 superlab files into 1!

Hi SCL,

I’m so sorry to have left you unattended. Our forums’ email sender was broken for a day or two, and I did not receive notification of your continued feedback.

I am certain that your command-line goal can be met. It is just a matter of finding the right mix of bash script commands and osascript syntax.

Here is something else you can try:

Type all of these commands one at a time in Terminal:


touch ~/raise_superlab.sh

chmod 0755 ~/raise_superlab.sh

echo “sleep .3” >> ~/raise_superlab.sh

echo "osascript -e ‘tell application “SuperLab 4.5”’ -e ‘activate’ -e ‘end tell’ " >> ~/raise_superlab.sh

echo “” >> ~/raise_superlab.sh

I recommend that you copy and paste them one at a time.

What those commands do is create a very short script file. Once the file is created according to those commands, then you do not need to ever repeat those commands again. In other words, those commands are a one-time-only preparation step.

After that preparation is complete, then the new command that you should try to use for launching the experiment will look like this:

/Applications/SuperLab\ 4.5.app/Contents/MacOS/SuperLab\ 4.5 --nosplash -r -q -e “/full/absolute/path/to/experiment.sl4” -o “/full/absolute/path/to/savefile” -n participant -g “Main Group” & ~/raise_superlab.sh

(Note: this thread has now spilled over onto page two.)

Here are some errors/malfunctions that happened to me while I was testing my most recent suggestion:

  • [I]"execution error: File ______ wasn’t found. (-43)"[/I]
  • two dock icons for SuperLab showing in the dock simultaneously
  • the experiment ran but Terminal stayed in the foreground (like before)
  • [I]"-bash: /______/raise_superlab.sh: No such file or directory"[/I]
  • [I]"-bash: /______/raise_superlab.sh: Permission denied"[/I]

If any of those malfunctions happen on your computer, then I can suggest continued adjustments that might help.

Hi Kelly,

Thanks a lot. It looks like with the addition of the osascript calls in the raise_superlab.sh script things are working well. The terminal is hidden and superlab seems to run fine.

As a follow up. We have been using this method but it is quite unreliable. If the computers we are using pause for a moment at the wrong time then this method for bringing superlab to the front doesn’t reliably work. I’m trying to work on a more reliable solution but so far we haven’t been able to find a satisfactory solution.

Thank you. I truly appreciate the follow-up. Your feedback will help us prioritize current and future testing with the latest Mac OS X desktop behaviors.

I apologize that I do not have additional command-line tips for you.

As a sidenote, however: it makes me a little wary (just in general) that the computers are able to pause at the wrong time. Are there background processes running that can be stopped/killed to help eliminate these pauses? Have you looked at the ‘login items’ for the relevant user account to see which things get launched silently and automatically upon login? Perhaps some items can be eliminated. “Launch Daemons” are another set of processes that might be silently launched and consuming resources in the background. (these are typically configured by plist files in /Library/LaunchDaemons/).

Eliminating unnecessary login items and launch daemons is a general recommendation for anyone wanting to maximize the performance of a task (a SuperLab task or otherwise).

Hopefully that helps, but it seems likely to me that you may have already tried this particular angle.

Thanks again for the update.
Kelly