user x has a cron job that looks in a dir and moves teh files from 1 name to another except its not working correctly.
. /user/.profile # sorce the users profile
for file in `ls`; do
mv $file $file.`date +%Y%m%d%H%M%S``microsec`
done
microsec is a binary with 555 perm. on it in /usr/local/bin.
/usr/local/bin IS in the users path && from a shell prompt as that user i can run microsec and it will display the microseconds.
when i run the script by hand everything works. but when it runs via cron the file will get the date but not the microsec.
any hints?
RTM
August 15, 2002, 9:30am
2
Hint 1: user X does not have /usr/local/bin in their PATH
janr
August 15, 2002, 9:49am
3
When you load the .profile can be handy top point to the users homne directory by using ~<username>/.profile
in this case u are sure the right profile is loaded
when a script is NOT working in the cron BUT it does by hand, the problem is mostly a envirnment problem.
so use instead
. /user/.profile # sorce the users profile
~x/.profile Where X is the username
Why not just use the full path to microsec in the cronjob?
That way, you don't have to worry about pathing for the individual user and if the cronjob is ever moved to another user, you are still good to go. And if another admin has to work with this cronjob, the placement of microsec is obvious.
you know what really makes me mad. when people over write a profile on an account they are NOT supposed to use.
i guess its my error for not double checking the PATH. ;/
its working liek it should now (after i fixed the path)
I must reluctantly agree with Auswipe.
It is a good practice and good security to ALWAYS use the full path in any cron entry and in the scripts that you write.
The reason for this is, it is a very easy way for someone to replace any binary on your system with a trojan.
Always use full path AND always keep a backup copy of crontab for all users that have one especially cron.
hehehe