in reply to cron/perl interaction gotchas i am missing?

cron doesn't give control back to the script after the wget.
What do you mean by that? Cron isn't somekind of god that picks apart a program and deals with each piece of code individually. All that cron does is look at its watch, say "it's 10 minutes past 4!", fork, set (e)uid and pipe-open /root/crons/downloadsyncs.pl. Cron doesn't care what kind of external programs the script calls, and it certainly won't call those programs on the scripts behalf.

What you should be aware of when calling programs from cron (any program, not just Perl programs), is that you will have a limited environment. There's no user calling the program, and there's no login-shell involved either. There won't be many environment variables, PATH will likely be different than running something from the command-line, and so will your current working directory.

Abigail

Replies are listed 'Best First'.
Re: Re: cron/perl interaction gotchas i am missing?
by schweini (Friar) on Jan 30, 2004 at 13:12 UTC
    sorry - i have a tendency to antropomorphize daemons...
    what i wanted to say is that that it seems to me that cron wait()s for the wget-subprocess to finish, and then calls it a day...almost as if i would've called exec() instead of system() in my script...

    and i can't figure out how the enviroment influences my poor script, since it does run fine...til the wget returns....
[reply]
[d/l]
[select]
      Anyway it might have something to do with the environment the script is running in ...
      - what user's crontab is this? (root?)
      - show us the code of the script called 'root'
      then we might be able of helping you ...
      pelagic

      update:
      I just read YOUR update ... no more ideas left on my side ... besides: stay up and watch the script running at 0410 ...
[reply]
        it's /etc/crontab, and 'root' is the username, which MDK ssems to use in it's crontab format....
[reply]

In Section Seekers of Perl Wisdom