This is my first post here - I barely know much Applescript but I’ve been having some fun with Automator. I did do a thorough Google search (including Google Groups) and a search on this site before deciding to post.
Though I did find a solution to my initial problem through other means, my search brought up a few generic questions I could not find adequate answers for:
Is there a way to convert Automator applications to Applescripts?
Why doesn’t Apple Mail allow Apple’s own Automator in its rule options, instead of just Applescript?
Are Applescript and Automator really that divergent, or is this something that Apple is diligently working to correct?
Any and all replies much welcomed. Thanks
Model: iMac G4
Browser: Safari 416.12
Operating System: Mac OS X (10.4)
Welcome. Hopefully you’ll find all your answers here.
Automator actions can’t be converted to AppleScripts. Automator workflow scripts are xml files with action calls in them. Most actions could be written out of applescript code. Here are a few psedoactions written this way:
But it would be inefficient to reconstruct AppleScripts out of pseudoactions.
I think it’s because Automator is mainly designed for automating repetitive tasks that apps can’t do. Since Rules already automates processes, Automator would just be duplicating tasks that Mail can automate.
AppleScript is designed to do very specific tasks. And you have to know AppleScript to be able to do it. Automator is designed for building very generic tasks quickly, with no coding required.
That being said, most actions are just AppleScripts in disguise. The Run AppleScript and Run Shell Script actions can add all the functional ability of AppleScript and UNIX to any Automator workflow.
Certainly an AppleScript can always be written to do what Automator does, but at this point there’s no direct translation that I know of.
Because Automator is brand-spankin’ new, and the version of Mail that came with Tiger didn’t include “awareness” of Automator although Mail is scriptable. It probably will get rountuit eventually.
Who knows what Apple has in mind? The problem with Automator as it now exists is that it cannot include decision branch points - it’s a single straight line start to finish, something like “Record” in AppleScript. By the way - Record is a reasonable way to find out how to do some things in AppleScript and this board is always ready to help.
Thanks Kevin and Adam for your fast and clear replies.
I have an Applescript course on my computer, but haven’t found the time to go through it. It’s also only an occasional need. But I recognize its power and inherent simplicity, though not as simple as the wondeful toy Automator, which does give considerable satisfaction to wannabe Applescripters like me who have not quite gotten around to…
Now if only Automator had decision tree abilities as you say, that would certainly take it to the next level.
Anyway, all this has whetted my appetite for custom programming on my Mac, so I’ll see what comes of it. In the meantime, I’m glad to have discovered this board - what a great resource!
I started exactly opposite, I am familiar with AppleScript and am new to Automator.
One of the main differences I have found between Automator and AppleScript has to do with the logic one applies to solving a problem - AppleScript allows for some quick and dirty solutions that will solve one distinct problem (and thus are not very re-useable), whereas Automator requires the problem to be broken into very small logical pieces that are each solved with an action and assembled into a workflow (and they become very re-useable).
I often have problems when trying to create an Automator workflow because the actions I find do not catch all the errors I encounter and fail part way through execution - so writing a quick AppleScript that looks for these errors and deals with them (a branched logic Automator can’t handle very well) is a much quicker and more complete solution. However, using Automator forces me to be more thorough in mapping out my large problem into smaller problems, writing actions for each, and these become much more re-usable in the future.
I want to second what Adam mentioned about the versatility on this site for finding useful information as well as the simplicity (and fun) in learning Applescript.
Specifically, check out these links (which can be found on our Books/Resources page):
The first two are real books you can order via our links, or check your local library. The third is a PDF download that is free, and can be printed onto real paper. I do not want to knock any kind of computer based product you may already have, but I prefer paper references to get started. In fact, I bought the second book listed above (Missing Manual) on a whim and read nearly all of it before I even got the laptop out to try things out. As Adam stated, I was amazed at the simplicity. So, don’t wait until you have time on your machine; get something you can hold in your hands and read, and see if you want to learn more.
And stop back here often for advice and further details about your projects.