Cron doesn't have the same environment as you do when you run a script directly from the shell. For example, if your script is at /some/directory/script.pl and you have a text file at /some/directory/file.txt, then this will work from the shell when doing a "perl script.pl":
open F, "file.txt";
However, when the very same script is run from cron, the above code very often will not run, because cron doesn't have a default directory set. You can make it run with a
open F, "/some/directory/file.txt";
...which should work just fine. (This behavior is the same for "unlink" as well as "open.") In general you should always specify absolute pathnames for any script designed to run from cron.
Gary Blackburn
Trained Killer | [reply]
[d/l]
[select] |
Erm, I am presuming your script shall delete the file after it analized it?
If so, check for the user as whom your script gets executed by cron AND check the permissions of the file you want to read.
Have a nice day
All decision is left to your taste
Update
why:
If your script tries to read the file and doesn't die upon failure to such attempt, it will proceed and delete the file, for this it might have enough permissions :-)
On the other hand, what conditions do you check to attempt openening the file and are these the same conditions to be met to delete it? | [reply] |
correct ! should delete it after. This cron job is running as root and the file has 755 permissions with root as owner and group
| [reply] |
Well, so feel free to post some code you are using, so we can help you on that one, as its only guessing right now.
And NO, please don't post the full code, as the processing of the files content isn't the problem, but the rest of your script :-)
Have a nice day
All decision is left to your taste
| [reply] |
Check the environment the respective jobs are running under - as a quick and dirty hack, dump out the contents of the %ENV hash (sort on keys first), and compare. Generally, cron jobs often run under root's uid, which has a greatly restricted environment, possible because it doesn't execute a .profile script at the beginning of a session like a logged in user would.
I may well be wrong, but that would be a good first place to start. | [reply] |
somebody already mentioned permissions, but you may also want to specifically set your umask inside your script, depending upon how any output files are being used...
I once wrote a cron job that did a little auto-emailing of some aggregated numbers (from a flat file) overnight to users throughout our company...well, since I didn't set my umask, the permissions on files I had been updating overnight were set so that no one else could write to the files. Kinda freaked our users out ;) | [reply] |