osascript
 

Can any one explicitely explain or point me to some explicit information regarding the use of osascript - more precisely the use of osascript and its interaction with cron. I must have spent four hours last night perusing various posts around the net gathering information on the use of osascript with cron. Just when I think I got it down - it works once, then the next run it doesn't.

I am so confused now as to what works and what doesn't work!!!

Any help would be greatly appreciated!

is it cron or osascript?
 

hey bluehz,

i don't use osascript, but your symptom makes me wonder if it's a cron issue. can you get anything to run with cron using the schedule you want? take osascript out of the picture and see if you can get cron to execute a simple shell script on the schedule you want.

hope this helps,
mike

cron works perfectly for other shell scripts I have written, etc.

what's different
 

i've never used osascript, so i'm wondering what's different about it than running anything else from cron. is osascript a script itself? a binary?

one time in the past, i seem to remember a problem where the first instance of cron running something wasn't finished when cron tried the next instance. that caused problems. had to change crontab to run it less frequently.

good luck,
mike

bluehz,

Have you got osascript wrapped in a shell script or are you trying it bare?

I've had problems with cron and command line paramters and now always wrap things in a shell script.

Tony

I have it wrapped in a shell script - runs fine manually, runs fine through cronnix, just refuses to run via cron activity. Really irritates me that cron task have to be this hard. Shouldn't be like this.

i'm seeing more of this and it makes me wonder: does your scriptage do anything that requires a head or terminal or an instance of the finder?

could you post the meat & potatoes of your scripts, the crontab command line and any meaningful errors?

No problem - although what I am posting is somewhere near variation 999 that I have tried to get to work in cron. Its really quite a basic script - all I want it to do is regularly update the Library in iTunes by scanning the ~/Music folder. It checks for iTunes and launches it if it is not runninng already. Should be no big deal....

This is the shell script that is 'run' by cron....saved in a text file add.sh, proper permissions granted.

I have tried the crontab as both the user and also the system crontab - neither works, but it seems like the system crontab works best/closest. This is the cron entry (system crontab)

23 11 * * * root sh /path/to/add.sh

yields this error (reported via cron mail):
syntax error: Can't get the application's event dictionary. (-2709)

----

I have also tried saving the script as a compiled applescript....add.scpt, proper permissions, etc.
and launching from cron:

23 11 * * * root /usr/bin/osascript /path/to/add.scpt

which yields this error:
execution error: Finder got an error: Application isn't running. (-600)

None of these will work (and many other variations I tried).

Obviously - I have edited them abit to remove personal data - /path/to, etc...

this is what i was afraid of. the dreaded -finder got an error: app isn't running-

i stripped that osascript call down to tell finder do shell script open itunes and it gakked.

there is something missing in a headless cron sh environment that a call to osascript gaks on. the -600 error

i can find nothing about how to resolve this...

i suggest you make a very simple sh script to /usr/bin/osascript call, get the
-600 error and report it to apple.

You wouldn't happen to know what the 600 error is would you?

Thx for looking at it...

put the open in the shell script
 

Well if your Applescript is gakking on the opening of iTunes why don't you do that in your shell script before you run osascript.

Something like

# we subtract 2 - 1 for iTunes Helper and one for our grep process
if ! ( `ps ax | grep iTunes -c` - 2 ) open /Applications/iTunes.app

would do it for you if you make sure it runs in tcsh.

Tony

the only reference i could find is in this [ at least three years old ] documentation...

http://developer.apple.com/techpubs/...cript.10a.html

upon reflection, i really think this is the call to /usr/bin/osascript

try making the simplest thing to do in an osascript call and i'll bet it gaks from cron because osascript needs an environment that a headless cron sh process doesn't have.

the trick is to provide a more robust environment; i just don't know enough about AS to get you there.

would someone test my ASSumption above?

Thanks - thats my problem also - all the AS documentation is outdated. Very little info on OSASCRIPT if any.

A Workaround!!!
 

OK, after much experimentation I have a workaround for this problem.

If you have a shell script '/Users/myname/bin/shellscript' that contains an osascript command and you want to run it using cron.

Step 1.

Create a single line AppleScript that reads :-
do shell script "/Users/myname/bin/shellscript"

and save that shell script as an application called (for example) runshellscript.

Step 2

In your crontab you need to have a command :-

open ~/bin/runshellscript

and all will work.

Tony

Ok - that sounds good. If I understand this then - you are basically launching an AS app front-end to launch the shell script that launches the final AS through the OSASCRIPT cmd. Why would I want to do this instead of just including ALL the AS in the FINAL AS (that is run via the OSASCRIPT) into the first AS application? Understand?

My whole point was to really avoid the AS application of possible. In my experience - the whole process of launching the app either interupts your work flow, pauses the machine, changes the frontmost app, etc....only occurs when the AS is run as a standalone-app...thats why I was trying to run it via the compiled script instead.

I guess there are probably means to create the initial front-end AS app to be less intrusive. I am no AS guru - so I am not really familiar - maybe "igoring..."

Thx for the info though - I think we are getting somewhere....theoretcically we could create the frontend AS app to accept variables and it could be a frontend to all the AS you want to run from cron/shell, etc.

I believe that the problem is in CRON
 

cron has an oddity that catches lots of UNIX programmers - it doesn't load the user's environment when it executes. Things like the PATH, environment variables, etc... don't get set.

I'm trying to work this out now, I'll let you know if I figger anything out!

Oh, sure, I understand. But in some instances it's much easier to do a bunch of stuff in Perl or the shell than it is in AppleScript but you need that little bit of AS. Much more powerful languages. The reason I solved it was for someone who wanted to load a particular desktop picture based on the time; hard work in badly documented AppleScript, dead easy in well documented Perl.

OK, it's not ideal, but it does work - and while it does bring up the AS as an app it quits right back to exactly the same app you had running in a matter of a second or so - before the shell script it calls completes.

It also proves that the problem isn't cron but osascript. It appears osascript doesn't like being called from a headless app. I'm going to try for a better solution, but this one works in the meantime.

Tony

What the heck is a headless app?
 

If you mean "A background app" then why does

work correctly? Things don't get more "headless" than that.

Re: I believe that the problem is in CRON
 

While the users environment isn't set the defaults are, so you actually get quite a lot of the environment variables and the best bits of PATH (like /bin /usr/bin).

In the case of osascript it is actually the headlessness that seems to catch it. Build yourself any headless app and you will discover that it has all the same drawbacks as cron visavi the environment you get exposed. An easy way is to use Apache to run a Perl script and guess what, you have osascript gakking in exactly the same way.

Tony

You're still going to have to define "headless"
 

What is a "headless" application? I know about background apps, foreground apps, daemons, nohup and kernelspace, but I've never run into a "headless" application.