On Aug 19, 2009, at 17:54 , James Dinkel wrote:

> sorry for the silence, I've been swamped today (consultants are here
> doing a networking hardware upgrade).  However, I was incorrent in  
> that
> '/.*/.match("myrandomstring")' does actually return a match when run
> from cron, but my actual regex is a bit more complicated.  My actual
> regex does match when run manually though.
>
> I think I'm going to do a little more testing and cut some parts out  
> of
> the regex to find if maybe there is just a single unit of the  
> expression
> that is the problem.  It's a tedious pain in the rump, though since it
> matches when run manually, I have to make a change, check the time,  
> set
> it to run in a minute from cron, wait for it to run, check the output
> file... very tedious and time-consuming.
>
> This is run by root's cron by the way.  I don't how to do "sourcing
> .login or .profile" but I did try making a wrapper script with a
> /bin/bash hashbang that then just calls the ruby script, and that  
> didn't
> make any difference.

I can almost guarantee it has nothing to do with cron itself.

You can start to isolate your problems in a couple of ways. One thing  
I use is:

alias newshell='env -i $SHELL --norc'

that brings up a new shell in your terminal that is about as virginal  
and bare as what cron runs with.

Another is to set up a side cron task like:

* * * * * /usr/bin/ruby -e 'p /.*/.match("myrandomstring")'

and wait for the mail landslide to start (or tack on 2>&1 >> /tmp/ 
cron.wtf)

 From there, build it up until you can replicate your problem  
properly. Pathing, system calls, tainting/SAFE modes... whatever it is  
that is actually tripping you up. Find it.

Good luck.