perl and apple mail?

[Joel Rees]

Are any of you using perl plugins with apple's mail browser?

What I'm thinking of is something along the lines of supplementing  
the overly-simple rules in apple mail with some perl re. Things like  
funneling all the broken header junk off the top and into one folder,  
catching the real sharpos that like to put my mail address in the  
return address of the junk mail and putting that in a separate  
folder, that kind of stuff.


I'm sure it could be done with the scripting api, but I'm always all  
thumbs with applescript.


I've been looking around the web, and there are tantalizing clues,  
but not enough for a lame-brain like myself to grab hold of.


If anyone is doing something like this, can you hit me with a cluestick?

Joel Rees
(waiting for a 3+GHz ARM processor to come out,
to test Steve's willingness to switch again.)

Re: perl and apple mail?

[Chris Devers]

On Mar 10, 2008, at 7:24 AM, Joel Rees [EMAIL PROTECTED] wrote:


Are any of you using perl plugins with apple's mail browser?


What, you mean aside from SpamAssassin  procmail?

I've always felt it was easiest to just filter everything on the mail  
server, and not bother with whatever filtering abilities the mail  
client I'm using this month may or may not offer.


But then, I suppose this isn't a viable approach if you can't run  
software on the server.


If you can get off the ground at all in filtering with AppleScript,  
its fairly easy to just write '...do shell script...' and switch to  
Bash / Perl / etc from there. That may be a good approach here.


That or fetchmail piping into local SpamAssassin/procmail/etc filters,  
but oh look I'm getting silly again.



--
Chris Devers

Re: How to run Perl script at Mac OS (Darwin) Release?

[Packy Anderson]

On Mar 9, 2008, at 11:12 AM, Doug McNutt wrote:
Hashing of tools by shells has not been mentioned. It may not be  
part of the problem but on invocation many, if not all, shells  
examine the $PATH variable and make a table of executables that it  
finds. The table is then converted to a hashed lookup array in  
order to improve speed of response. (That probably makes little  
sense today but it was started during the days of mag tape.)


So if you create a perl script, place it somewhere in $PATH, and  
set its execute permission a running shell will not find it. A full  
path, perhaps starting with the current directory  .  always works.


In tcsh the command to rework the hash of tools is rehash.  
Restarting the shell with a new Terminal.app window will do pretty  
much the same thing.


It's not likely that Gary is having problems with his shell creating  
a hash table of executables on startup; he's using bash (the default  
in OS X these days), and bash doesn't do that:



 test1.pl
 -bash: test1.pl: command not found



If he had created test1.pl in a directory in his path (say, /Users/ 
gary/bin) but the executable bit wasn't set, he'd have gotten the error


-bash: /Users/gary/bin/test1.pl: Permission denied

even if the file was created after his bash shell started.  If he  
then had the executable bit set properly (chmod +x test1.pl) and  
didn't have a perl installed at /usr/local/ActivePerl-5.10/bin/perl,  
he'd have gotten the error


-bash: /Users/gary/bin/test1.pl: /usr/local/ActivePerl-5.10/bin/perl:  
bad interpreter: No such file or directory


Of course, maybe he's eschewing the default perl on OS X because he  
wants to use the 5.10 for some reason and he downloaded ActiveState's  
build for OS X; if that's the case, then that's probably the shebang  
line he wants.


Anyway, I'll shut up now, since people have just about beat this  
subject to death.  ;)


Here's hoping Gary's happily programming perl on his Mac now...

-packy

--
Packy Anderson   
[EMAIL PROTECTED]


If I had a boat, I'd go out on the ocean;
And if I had a pony, I'd ride him on my boat.
We could both together go out on the ocean--
Me upon my pony on my boat.