Can anyone tell me what status 13 means in launchctl list?
I have loaded and started a job, but it doesn't actually run the AppleScript its supposed to. The only info I can see is that it has status '13', but I can't find any info on what this status means.
OS X Mountain Lion (10.8.2)
That's the status that the particular job exited with. It's typically specific to the job, too. Check the log for the job for details.
The file /usr/include/sys/errno.h suggests that the error [13] is "Permission denied".
Hmm...thanks, Mark.
Not sure how to work around that. It's a plist I created and placed in my ~/Library/LaunchAgents folder.
The address of the script its supposed to run is in a folder in my home directory. Maybe I need to move that script to somewhere in ~/Library folder? Though I can't see why that would make sense. I'm running it from within the user account in which I'm logged in.
launchd is picky about permissions (for security reasons). make sure that both the launchd plist and the script you're trying to run are owned by your particular user.
Yup, they are. They're both 644. -rw-r---r--
well, at this point you're going to have to post the launchd plist and the script. We can shoot in the dark all day without hitting anything; time to throw some light on the target.
OK, looks like my mistake was thinking that a plist could invoke an AppleScript directly. Is that not the case, then?
I've got it working now by having the plist invoke a Bash script containing an osascript line to invoke the AppleScript!!
If I'd known I was going to have to go down that route, I'd have just written the original script in Bash and not bothered with AppleScript at all!
Oh well, at least its working now...😎
plists can invoke applescripts directly; use osascript to call the script file or build the script line by line.
Do you mean you can use osascript in the plist itself?
This is what I actually did, in the end:
Step 1: have launchctl load and run the plist:
<?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>Label</key>
<string>com.applehelpwriter.duplicate-bin</string>
<key>ProgramArguments</key>
<array>
<string>/Users/sphil/bin/duplicateBin</string> -- this is shell script file
</array>
<key>StartInterval</key>
<integer>86400</integer>
</dict>
</plist>
Step 2: run the file /Users/sphil/bin/duplicateBin
This contains one line: osascript ~/bin/AppleScripts/duplicateBin.scpt
Step 3: run duplicateBin.scpt
This is a standard AppleScript file with handlers and variables that does the work I actually want done.
Now, I could have cut step 3 and just written a Bash script to do the job that the AppleScript was doing, but since I didn't realise any of this till after I'd already spent time writing and testing the AppleScript, I guess I'll just keep it as it is.
However, if there's a way to get from the plist directly to the AppleScript that'd be worth doing. One less operation to invoke = one less thing to get broken!
ProgramArguments can take any bash command, where bash space delimiters are represented by separate strings. so do this:
<?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>Label</key>
<string>com.applehelpwriter.duplicate-bin</string>
<key>ProgramArguments</key>
<array>
<string>osascript</string>
<string>~/bin/AppleScripts/duplicateBin.scpt</string>
</array>
<key>StartInterval</key>
<integer>86400</integer>
</dict>
</plist>
One gotcha. launchd by default does not expand shell tokens, so you'll either need to spell out the full path to the script (the preferred method) or else set the EnableGlobbing key to true (only do this if for some reason you need a load-time path that needs to point to different files for different accounts).
If it's not a long applescript you could write it directly in the plist file as well, though that gets a bit cumbersome (you essentially copy the entire script in to string blocks, with -e in a string block before each code block).
Excellent! That's precisely what I was after. 🙂
launchctl list status 13
