Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have written an AppleScript that lets me back up a particular file. The script runs fine inside AppleScript Editor: it does what it's supposed to do perfectly. So far so good.

Now I'd like to run this script at timed intervals. So I use launchctl & .plist to make this happen. That's where the trouble starts.

  • the script is loaded at set interval by launchctl
  • the AppleScript Editor (when open) brings its window (with that script) to the foreground but no code is executed
  • when AppleScript Editor is not running, nothing seems to be happening at all

Any ideas as to why this is not working?

--

After editing (as per Daniel Beck's suggestions) my plist now looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<false/>
<key>Label</key>
<string>com.opera.autosave</string>
<key>ProgramArguments</key>
<array>
<string>osascript</string>
<string>/Users/user_name/Library/Scripts/opera_autosave_bak.scpt</string>
</array>
<key>StartInterval</key>
<integer>30</integer>
</dict>
</plist>

and the AppleScript I'm trying to run:

on appIsRunning(appName)
    tell application "System Events" to (name of processes) contains appName
end appIsRunning

--only run this script when Opera is running
if appIsRunning("Opera") then
    set base_path to "user_name:Library:Preferences:Opera Preferences:sessions:"
    set autosave_file to "test.txt"
    set autosave_file_old to "test_old.txt"
    set autosave_file_older to "test_older.txt"
    set autosave_file_oldest to "test_oldest.txt"
    set autosave_path to base_path & autosave_file
    set autosave_path_old to base_path & autosave_file_old
    set autosave_path_older to base_path & autosave_file_older
    set autosave_path_oldest to base_path & autosave_file_oldest
    set copied_file to "test copy.txt"
    set copied_path to base_path & copied_file

    tell application "Finder"
        duplicate file autosave_path
        delete file autosave_path_oldest
        set name of file autosave_path_older to autosave_file_oldest
        set name of file autosave_path_old to autosave_file_older
        set name of file copied_path to autosave_file_old
    end tell

end if
share|improve this question
    
Don't you think it'd be useful to post your launchd plist content? –  Daniel Beck Apr 13 '11 at 7:57

2 Answers 2

Save the script as application in AppleScript editor (File » Save as…), or change the call in your launchd plist to open osascript (the Terminal way of executing AppleScript) with the script file as argument.

share|improve this answer
    
Thanks so much for your quick reply Daniel. Your suggestions did the trick. It turns out that there's more to the code that I did try to run: it included "if file exists" statements and while that was fine within AppleScript Editor, it ran into problems when firing through osascript or running as an application. Would be nice to solve that issue, but it's more like "icing on the cake" right now. FYI, the script is meant to back up Opera sessions on OS X just in case someone accidentally closes a window with many active tabs... –  Daktari Apr 13 '11 at 10:57

Seems to be affected by this:

So if you run a script “by hand”—whether from AppleScript Editor, from within Automator, or as a standalone app or droplet—it should be able to do whatever it’s scripted to do, just as it can today. Put another way, you should be able to continue to run scripts by hand just as you always have.

Internal application scripts: Some apps use “internal” AppleScripts to handle certain actions of their own. (For example, BBEdit ( ) uses such scripts when it installs its command-line tools.) Such scripts are built into the app; you never see them in menus or elsewhere. Such self-referential scripts should continue to work as they always have.

If, however, a sandboxed app wants to use AppleScript to interact with another app or with other parts of your system—a menubar app that uses AppleScripts to control iTunes, say—then the new restrictions will come into play. A sandboxed app can’t use AppleScript to communicate with another app on your Mac, unless the developer specifically requests (and receives) an entitlement to do just that.

http://www.macworld.com/article/1165641/how_increased_mac_security_measures_will_impact_applescript.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.