in reply to Re: Running a perl script automatically on Mac OS X 10.5
in thread Running a perl script automatically on Mac OS X 10.5

Thanks for the quick response.

I'm having a bit of trouble and I think it's just related to my ignorance of UNIX. I created the text file, cron.txt as you suggested. I then did the whole "crontab cron.txt" thing. My question is, after the first 5 variables are declared (Minute, Hour, etc.), what is the "sixth" variable exactly? I thought it was the command that I would execute if I was at the command prompt. So, for me, I put in something like perl -w ~/path/to/script.pl.

I guess I should put the whole thing

23 13 * * * perl -w ~/path/to/script.pl

But, it doesn't seem to execute. What to do?

Replies are listed 'Best First'.
Re^3: Running a perl script automatically on Mac OS X 10.5
by Perlbotics (Archbishop) on Sep 05, 2008 at 21:29 UTC

    Hi, I don't know much about OS X, but some OS have additional security restrictions. E.g., your UID might need to be listed in /etc/cron.allow and not in /etc/cron.deny (ALL matches every user) to be eligible to execute cronjobs.

    Usually cronjobs are executed under plain /bin/sh, so you might explicitly want to change that. Furthermore, I would not trust tilde expansion. It might work, but using $HOME/path/to/script.pl or even manually expanding ~/ might help here. Most cron systems allow to set SHELL and HOME in the cronjob file.

    Perl should be in your $PATH, but expanding that to /usr/bin/perl - or wherever perl is installed on your system is more reliable and secure. If your script.pl accesses some non-standard environment variables (i.e., via %ENV) you might need to explicitly start your standard shell (see: /etc/passwd) or use a wrapper.

    So, you might end up with: 23 13 * * * /usr/bin/perl -w /home/prince9/path/to/script.pl
    where /home/prince9 is the output of echo ~ and /usr/bin/perl is hopefully the output of type perl ... have a look at e.g. /var/log/messages too...

      Had to go away for a few days. Okay, so here is what I have done. In my cron.txt file I now have the line 21 08 * * * /usr/bin/perl -w /Users/myname/Documents/path/to/CronTest.pl. I copied that "sixth variable" part (the part starting with /usr and all the way through /CronTest.pl) to the command line in my Terminal window and the script executed fine, so I know that command part of the cron listing is correct. (BTW, what is that "sixth variable" called? In my mind I'm calling it the command, but am not sure if this is correct.)

      It was 8:19 a.m. when I saved the cron.txt file and still 8:19 when I entered crontab cron.txt. I checked crontab by entering crontab -l and it appeared to be correct. When 8:21 rolled around, however, nothing happened.

      If you think this is a security issue, could you be a bit more specific about what I might have to do (My exposure to UNIX is limited and occurred about 15 years ago.)

      If not a security issue, what might I be doing wrong?

      Thanks for your help!

        Right, my man pages call the sixth argument command, it's the whole thing /usr/bin/perl -w /Users/.../CronTest.pl.

        First, please check /var/log/messages or /var/log/warn (maybe there is someting in /var/adm/ too, it depends on the OS) if something suspicious happened around 08:19-08:21. It is AFIK important that your crontab file ends with a linefeed but not with an empty line! So please check that too.

        How does your Perl program displays that it has done something? Does it create a file or a log-entry? Do not expect to see something in your terminal or in your X window (you can redirect console though). If your program sends something to STDOUT or STDERR, you'll usually get an e-mail. So have a look at /var/spool/mail/myname (or the location where your system locally stores e-mails). For further experiments, I suggest to use a simple cron-command like /bin/date >> /tmp/mycrontabcheck.txt. Each time, your cronjob is executed, it is documented in /tmp/mycrontabcheck.txt

        I would be surprised if your cron-daemon is not running..., however  ps -elf | grep cron | grep root should come up with something like /usr/sbin/cron or ...crond.

        Security: man crontab explains what you have to do regarding the /etc/cron.allow and /etc/cron.deny issues better than I can do here, but shortly: if /etc/cron.allow exists, your UID (myname?) must be a single linefeed terminated line in this file. If this file does not exist, your UID must not be listed in /etc/cron.deny (neither: ALL).

        you are not checking error logs/messages
Re^3: Running a perl script automatically on Mac OS X 10.5
by graff (Chancellor) on Sep 06, 2008 at 01:36 UTC
    Cron jobs tend to run in a less "rich" environment, so you do need to be more explicit about things like paths. In particular, cron on (BSD-based) macosx uses "sh" instead of "bash", which means that the tilde is treated as just a tilde, not a special abbreviation for $HOME. However, cron will start you out in your home directory, so instead of tilde, you can just use period. Also, your PATH will be limited to "trusted" directories (not including ".") If your perl script begins with the standard shebang line:
    #!/usr/bin/perl
    and if the current "mode flags" on the script file allow it to be executable (use the chmod +x to make the script executable), then your crontab entry can simply be:
    23 13 * * * /absolute/path/to/script.pl
    (plus any args that the script might need for its @ARGV). Note that if the script writes anything to STDOUT or STDERR, this material will be sent to your mac login account as an email message (check out the unix "mail" command), unless your cron entry includes redirection on the command line, e.g.:
    23 13 * * * ./mypath/to/script.pl > cron.out 2> cron.err
    In that example, "./" represents your home directory, which is where the output files will be created.