I have a script that can sometimes take hours to run. The part that takes the time is a shell command run via do shell script. Depending on what you are doing, it can take seconds, or hours. When its done, it also throws up a display dialog letting you know its complete.
Then this script runs for many hours, it ends with a timeout error. Is there a way I can see exactly what line triggered the timeout?
It shouldn’t be any line. Both of these commands, the do shell script and the display dialog after it, are in a block of with timeout of 259200 seconds, which is 3 days. This script I just ran took several hours. But not that long.
ALSO the dialog has a giving up after 300 seconds attribute so it doesn’t cause a timeout while its waiting for you to hit ok. And again, the dialog is inside the timeout block too.
So everything looks correct, and yet I still get a timeout error. Is there an error console I can use to dig deeper somehow?
l008com. The purpose of a with timeout statement is defined in the AppleScript Language Guide (here) as quoted below, and I would question whether this statement will do what you want (it doesn’t in my testing). However, my knowledge on this particular topic is limited, and perhaps another forum member with a better understanding can offer an opinion.
Specifies how long AppleScript waits for a response to a command that is sent to another application.
It seems likely that the error is caused by the time it takes the do shell script command to execute, and, in that regard, you should consider the following from the Apple technical note (here).
My script will produce output over a long time. How do I read the results as they come in?
Again, the short answer is that you don’t — do shell script will not return until the command is done. In Unix terms, it cannot be used to create a pipe. What you can do, however, is to put the command into the background (see the next question), send its output to a file, and then read the file as it fills up.
So, based on the available information, you might try one of the following:
Edit your script to write a string containing completed commands (and error messages if available) to a text file to troubleshoot the issue.
If your script works as you want, and the only issue is the error message, you might simply suppress the error message. This is normally done with a try statement but another approach might be applicable depending on your script.
Another option would be to attempt to run the shell command in the background, although this strikes me as a really bad idea.
BTW, troubleshooting an AppleScript that can take hours to complete is a bit of a nightmare. I don’t envy you this task.
Be aware that with timeout of affects only lines which send AppleEvents (communication between applications, calling handlers, read/write properties or elements). Scripting additions like do shell script line do not send AppleEvents.
Update: Turns out they’ve added some debugging tools to the script editor since System 7.1 . . . So I ran my script in the editor and turns out, it is my dialog that is causing the timeout error, not the do shell script. What is up with that?
Here is the function:
on RunCommand(MyCommand) withtimeoutof 259200 seconds set progress total steps to 1 set progress description to “Creating Disk Image” set progress additional description to “Please wait while your new disk image is created…” set progress completed steps to 1 delay 0.1
do shell script MyCommand
–display dialog MyCommand
set progress total steps to 0 set progress description to “Disk Image Creation Completed!” set progress additional description to “” delay 0.1 display dialog “Your disk image has been created!” buttons “OK” default button 1 with icon note with title MyName giving up after 300 endtimeout end RunCommand
Its the completion dialog thats giving a timeout. But it goes away after 300 seconds. What is the deal with that?
Ok I can recreate my problem with a much simpler script. Which excludes the do shell script command entirely.
delay 14401
display dialog "Your disk image has been created!" buttons "OK" default button 1 with icon note with title MyName giving up after 300
This throws a timeout error once the dialog ‘gives up’. Is that how this is supposed to work? Is the solution to just wrap a try around the dialog line?
How are you running the script in production?
From script editor, an AppleScript app, the script menu, osascript, etc…
Display Dialog will cause an error if the process is not frontmost.
If run from Script editor or AppleScript app, you need to put an activate command before the display dialog. If run from script menu or osascript, since it not run from a GUI application, you need to have another GUI app handle the Dialog like so…
tell application "loginwindow"
display dialog "Got it!" giving up after 5
end tell
I would not tell the finder, but use login window instead. Because Finder would also be needed to activate to make sure it’s in front. Login window you don’t
So this is kind of obvious, but putting the display dialog in a try / end try suppresses the error.
Also simply putting an activate before the display dialog also seems to avoid the timeout error. I’ll add the activate fix to my script and see if it works in the real thing (not just the test script). Actually giving this more thought, I’m not sure which option I’m going to use. One of these two. v1.0.4 coming in hot!
So this behavior is a little weird. If you activate before throwing the dialog, then even if you switch right out of the script editor and go back to another program, the dialog will still give up quietly. I would have thought that would throw the same error and I would have thought that try was going to be the only way to avoid this timeout error. So, activate it is
This works if the script is running gas an application or under Script Editor or under Script Debugger. It has proved stable no matter what situation I have thrown at it over some years of AppleScript development
## Initialize
## within the script initialization section - works even in a handler in a script library)
copy (get name of current application) to parentProcessName
--or
tell application "System Events" to set parentProcessName to name of (first process whose frontmost is true) -- quick and dirty approach
---
## Do some stuff
## some other app may steal focus from the Scripts/Apps window
---
## User Interaction
tell application "System Events" to set wasFrontProcess to name of (first process whose frontmost is true) -- so we can give focus back afterwards
tell application "System Events" to set frontmost of process parentProcessName to true
display dialog "Some Dialog"
tell application "System Events" to set frontmost of process wasFrontProcess to true -- return focus to state before the user interaction
---
## Do more stuff
---
-- End of Script
33 Return focus to the Scripts/Apps window (if desired)
tell application "System Events" to set frontmost of process parentProcessName to true
