Skip navigation

Ensure AppleScript App Quits

937 Views 6 Replies Latest reply: Dec 4, 2012 5:48 PM by Hiroto RSS
Bernard Harte Level 4 Level 4 (3,025 points)
Currently Being Moderated
Nov 30, 2012 4:22 AM

I have an AppleScript saved as a run only app which I call every hour from launchd.


Most of the time it works fine, but occasionally something causes the app not to quit when it's done its thing.  This means that next time an error is thrown and the process does not run (so it fails until I force quit the app).


I have tried wrapping the whole script in a try...with timeout...end timeout...on error return...end try structure but that makes no difference.


The core of the script is a run shell script that calls a perl script which in turn gets data from a web site.  I have tried nesting a try...on errror...end try around this that simply sets the content of the variable that should be populated from the script in the event that any error occurs.


The final part of the script is opening a [text] file and inserting a few lines at the top.  Again I have tried wrapping this in a try...on error return...end try stricture.


None of these efforts seems to have any effect.  However, I can't get the script to fail when I run it from the ApplScript Editor.


Would I be better to use osascript to call a script rather than the app, or am I doing something more fundamental wrong?

MacBook Pro, OS X Mountain Lion, MacBook Pro Late 2011 8GB RAM
  • twtwtw Level 5 Level 5 (4,585 points)
    Currently Being Moderated
    Nov 30, 2012 10:08 AM (in response to Bernard Harte)

    This is way too non-specific for me to venture anything but the most generic advice.  You either need to show us the script or explain it more clearly.


    The one question I do have is if this script is just a wrapper for a perl script, why not run the perl script directly from launchd and skip the applescript middleman?

  • twtwtw Level 5 Level 5 (4,585 points)
    Currently Being Moderated
    Dec 2, 2012 4:17 PM (in response to Bernard Harte)

    Maybe, depending...  Of course, that's the last approach I'd usually try, because it's bound to be clunky.


    Don't get me wrong. I'm not asking you for more detail to be annoying.  I'm asking because without knowing what kind of hang/failure you're experiencing (or even what you're trying to do, for that matter) I'd just be shooting in the dark.  You want a formulaic answer, but there isn't one, at least not at this level of abstraction.


    Again with the generic advice: you do know that you can call a script app's handlers from other applescripts, right? So if you want to quit an app programatically just write a script that tells it to quit (or that calls a different handler that does cleanup before it quits).  That won't work if the script is truly frozen - Applescript is not threaded, so it has to finish one script command before it can begin another - but if the script app has simply stopped (as sometimes happens) it should still respond to handler calls.


    just out of curiosity, I'm assuming you saved this as a stay-open app (since part of the problem is that it stays open - lol); did you add an on idle handler?  without an idle handler the script will just sit there waiting for something to call one of its other handlers.  you need the idle handler if you want the app to check in periodically.

  • twtwtw Level 5 Level 5 (4,585 points)
    Currently Being Moderated
    Dec 3, 2012 8:59 AM (in response to Bernard Harte)

    A couple of style points that will make debugging easier.  If you use try blocks, use the following pattern (which gives error feedback) and put the try blocks around the smallest units possible (which helps identify where the error is happening):



      -- a command

    on error errstr

              tell application "System Events" to display dialog errstr


    end try


    keep in mind that a script app may not always report errors the same way as a running script, which is why I directed the DD to System Events.


    That being said, the only places it seems to me this script could get stuck are with the shell script and open file commands.  However, if the shell script were to hang it would not throw an error; the script would merely move on after 5 minutes, and you'd get an error that the variable theFlights has not been set.  forget that try block and do it this way instead:


    set theFlights to ""

    with timeout of 300 seconds

              set theFlights to do shell script "~/Documents/perl/ -x -c J -d 2013-09-07 ATH-LHR"

    end timeout

    File access can fail if there's already an open pointer to the file - Applescript only allows one pointer, and for some reason throws an error rather than returning the open pointer.  whenever I do file access during testing I use thin pattern, which tries to close open pointers and reopen the file:



              set theFile to open for access FlightCheckLog with write permission

    on error

      close access FlightCheckLog

              set theFile to open for access FlightCheckLog with write permission

    end try


    So, get rid of that all-encompassing try blocks, make the changes I've suggested to the other try blocks and the file open line, and tell me what happens.

  • Hiroto Level 5 Level 5 (4,815 points)
    Currently Being Moderated
    Dec 4, 2012 5:48 PM (in response to Bernard Harte)



    The 'with timeout' statement does not apply to osax command.

    Try the following code and see it returns true.


        with timeout of 1 second
            do shell script "sleep 3"
        end timeout
        return true
    on error errs number errn
        return {errs, errn}
    end try


    I think your perl script is hanging.

    Make sure it does exit or die properly.





More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.