Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.5: Run Automator workflows from AppleScript Apps
A couple of older hints, such as this one and this one, discuss running Automator workflows from AppleScript. Leopard, however, has built-in Automator support on the Unix command line, which can be called from AppleScript using the do shell script construct. This method also allows passing input values and variables to the workflow.

The basic form of the command is:
automator [-i inputs] [-D variables] /Path/to/Workflow
The -i option provides a list of inputs for the workflow, and the -D option allows temporary setting of workflow variables.

The trick to using this technique, however, is that the list of inputs (and assumedly the list of variables, though that's not made explicit in the man page) needs to be delimited by newline characters, and Unix is picky about the format -- it won't, for instance, accept \n as a newline character. (Thanks to the people over at the Apple support discussion forums for helping me figure that out.)

To call a workflow from AppleScript, use a subroutine like the following:
to run_workflow given inputs:inputVars, workflow:workflowPath
  set {tid, AppleScript's text item delimiters} to {AppleScript's text item delimiters, linefeed}
  set theInputsList to inputVars as text
  set AppleScript's text item delimiters to tid
  set cmd to "automator -i '" & theInputsList & "' " & workflowPath
  return do shell script cmd
end run_workflow
This routine is only set up to handle a list of input values (but could be adapted for variables), and returns the output value of the workflow to the script. Just be careful to keep the single-quotes in place to contain the linefeed-delimited list. If the workflow takes a long time to process, it might be advisable to put the do shell script command inside a with timeout block:
with timeout of 600 seconds --ten minutes
  set theResult to do shell script cmd
end timeout
return theResult
However, in my tests (making a PDF contact sheet of my entire Pictures folder via Automator), the script did not timeout.
  • Currently 2.71 / 5
  You rated: 3 / 5 (7 votes cast)

10.5: Run Automator workflows from AppleScript | 3 comments | Create New Account
Click here to return to the '10.5: Run Automator workflows from AppleScript' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Run Automator workflows from AppleScript
Authored by: Dr. T on Nov 13, '08 09:36:03AM

What is the advantage of launching an Automator workflow from the command line (which looks awkward) versus an AppleScript applet? It seems to me that double-clicking the AppleScript applet would be much easier, and a well-written AppleScript would be more flexible (about variables and file locations, since they could be specified each time the applet is run).

[ Reply to This | # ]
10.5: Run Automator workflows from AppleScript
Authored by: tedw on Nov 14, '08 02:31:11PM

the main advantage is that this method allows you to pass applescript variables <em>into</em> an automator workflow. I originally started thinking about this in the context of Mail rule actions. Mail won't (currently) accept automator workflows as part of rule actions, but it will produce lists of emails for applescript. there's no way that I can find to pass those Mail-produced lists to automator workflows for processing.

you can, of course, place an entire applescript in a 'run applescript' module (passing its result to the next action) - I'm not sure if there are any limitations on automator's implementation of applescript, but for normal purposes it should work fine. this is for those cases where (for need or convenience) you want to run the applescript directly and call a workflow with the processed data.

[ Reply to This | # ]
10.5: Run Automator workflows from AppleScript
Authored by: ocdinsomniac on Nov 14, '08 06:52:26AM

This is great, though the real story, for me at least, is that you can run Automator actions from the command-line, which means that I can now run workflows over SSH, which I actually may need to do in the near future. This works fine, with the one caveat: anything that depends on the WindowServer (the Mac OS X GUI) will fail if no user is logged in.

Anyway... Neat-o!

[ Reply to This | # ]