I was using the double applescript approach, and it made Mail.app hang.
I tried a few more times, and let Mail.app hang there - about 2-3 minutes the control came back, but there was no error message of any kind (well because I didn’t do “on error” and print the error message).
But if I saved the applet (the one that’s run by the 1st script from Mail.app) as “stay open” application, then everything is fine, except that the app will show up in my dock…
Since emails are coming in all the time, having an app appear every time (even in dock) is a bit distracting. Maybe there’s a way to hide a “stay open” app I guess?
Chances are it has to do with the run call to the applet (in the Mail.app script) not returning right away. Try encasing it in an ignoring application responses block. (But this could be a problem if it’s not okay for the applet to run asynchronously.)
If you’re getting a lot of eMails and calling the applet a lot, then it’s more efficient if it is a “stay open” applicaiton. I’m with you: I’d hate to have an icon always coming and going in the dock, or even just sitting there all the time, wasting dock real estate. There are ways to hide applications from the dock; one way is to make it a background application. Not sure how to go about that for an applet, offhand.
It’s also possible there are better ways of solving your problem rather than using Mail.app and AppleScript. If this is some kind of mail filter, it’s likely that a UNIX approach, such as a fetchmail and procmail combo, are better tools to use. You might want to refer to the Things eMail page for links to these and other eMail filtering tools and info, and also for SPAM countermeasures.
Thanks Rainy Day - you’ve been a great help. And you guessed it right - it’s for a spam filtering app (using regular expressions and other techniques) I wrote:
:idea: You might want to consider changing gears a bit and attacking the problem in a different way. By far the most powerful way of using regular expressions to filter eMail is to use procmail. So you could use fetchmail to collect mail from remote sources and procmail and/or other UNIX mail filters (e.g. bayesian) to filter it, drop the mail into a local mbox, then run a local POP server and let Mail.app (or any other eMail client) pick-up the mail from the local server. If you want to get fancy, you could send an AppleEvent (via osascript) to Mail.app telling it to fetch the mail in account so-and-so.
Now it would be possible to omit the local POP server and deposit the mail directly into Mail.app’s data files (since it’s in mbox format), then set Mail.app’s dirty flag so it knows to update its windows, but i’ve looked into this approach and don’t recommend it. There is much to go wrong, you would spend a great deal of time tinkering with it trying to make it work properly, and it is likely to break with future releases of Mail.app. The local POP server side-steps all of these issues nicely, has the advantage of being eMail client independent because any client may be used to collect the eMail from a local POP server, and using AppleEvents to tell the mail client to collect mail is a much more elegant approach, IMO.
The big advantage to this approach is it’s the best of both worlds. One can use the best UNIX SPAM filters available at the server level, and also take advantage of Mail.app’s filters. Also, for someone with multiple mail accounts from various providers, their eMail can be filtered in a consistent way across accounts. It’s essentially “server-side” filtering done uniformly across different providers; the only disadvantage is that the SPAM must be downloaded before it’s filtered, thus it does waste some bandwidth (but this is true of any client-side filter).
You could use AppleScript Studio to write a nice little installer/configuration app for the whole package. Would look very professional.
Well by hooking with Mail.app I don’t have to deal with mail fetching stuff (and this I fear can become hairy, given so many different mail server implementations exist out there). I also don’t need to worry about setting a local pop server… But I’ll definitely look into procmail to see what I can learn there.
I agree with your assessment (about directly messing with Mail’s own stuff). Right now JunkMatcher (my app) checks each incoming message, and keeps a record of them. Once Mail.app is done with downloading, JM jumps up to move the offending messages to either Junk or Trash mailbox, and marks them junk/read/flagged, etc as configured by the user.
Yes the package comes with a GUI configuration app called JunkMatcher Central (written using ASS), which allows you to do email forensics: testing/building patterns against a message loaded from Mail.app, browsing the log file, and other configuration stuff. But it’s still a work in progress.
I’m not sure how you’d go about hooking in procmail as a stand-alone filter, but i should imagine it could be done. Typically it’s called from an MTA as part of an eMail delivery system.
I know Preview is not scriptable, but I know that all applications recognize certain commands like open, close, etc. Is print one of those commands? I just want to have Preview print some PDFs as part of a script. Is this possible? If not, what’s a good application to use? Thank you for any help.
