Doug McNutt wrote:

> At 08:09 +0800 5/17/03, Andy wrote:
> >What is the difference between the way a program runs in a browser or telnet
> >window and as a cron job?
>
> There is no standard or error output though some servers convert the same to e-mails if you have other options set up like a .forward address in your home directory. My hosting provider allows execution of perl scripts but nothing else. It's silly because I can enclose a call to curl in back ticks from within perl.

You can (should, actually) capture stdout and stderr from cron like this:

    0 10 * * * /home/someuser/script > /home/someuser/script.out 2>&1

As Doug said, you can't rely on cron to capture the output for you, and even if it does, it will email it to the job userid on the localhost, which isn't necessarily going to make it to your mailbox. If you don't want to have to login to the server to check the script output, you can probably pipe it to email like this:

    0 10 * * * /home/someuser/script 2>&1 | mailx -s "script output" someuser_at_domain.com

> >Is it run as a different user? are rights changed when it runs as a cron
> >job?
>
> When, as a user, you use crontab to set up a table it is linked to the user who set it up. Jobs run under that username and his group settings. But. . . The user's login file is typically not executed which means that things like $PATH are not what you might think. Fully qualified path names in the crontab are best.

When you login to either the Bourne shell, the Korn shell, or Bash, it generally executes /etc/profile followed by $HOME/.profile. This doesn't happen with cron-executed jobs, because the shell isn't seeing it as a login. You can fake it, though, like this:

    #!/bin/sh
    . /etc/profile
    . $HOME/.profile

Once you've done that, your script should have the same environment as a regular login window. You could check it to make sure by inserting:

    env > $HOME/cron.env

somewhere near the top to record the environment that cron gives you.

Ralph Mitchell

-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful,
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
Received on 2003-05-17