No you'd have to source them.
However most of the time you don't really need the full profiles. Often your main issue is lack of PATH to binaries so you can just include those in the script you're having cron run.
e.g. Say you had a script that ran:
Code:
#!/bin/bash
date >>/tmp/mycron.log
ls -l / >>/tmp/mycron.log
The cron job might fail because it doesn't know where to find "date" or "ls". By adding full paths you get around this:
Code:
#!/bin/bash
/bin/date >>/tmp/mycron.log
/bin/ls -l / >>/tmp/mycron.log
For long scripts where you use the same command more than once it is more efficient to make the full paths of those commands variables then call them. (awk and grep are a couple I often do this for). So the above becomes:
Code:
#!/bin/bash
DATE=/bin/date
LS=/bin/ls
$DATE >>/tmp/mycron.log
$LS -l / >>/tmp/mycron.log
For very complex items you might wish to just set a PATH as you do in profile so you don't have to define a separate variable for each command:
Code:
#!/bin/bash
PATH=/bin:/usr/bin:/usr/local/bin:/opt/whatever/bin
date >>/tmp/mycron.log
ls -l / >>/tmp/mycron.log
Of course if they're are other variables you need from the profile you can just include those in the script.
Code:
#!/bin/bash
PATH=/bin:/usr/bin:/usr/local/bin:/opt/whatever/bin
MYDIR=/
date >>/tmp/mycron.log
ls -l $MYDIR >>/tmp/mycron.log
Of course if it's something fairly involved like an Oracle login where you have to set LD_LIBRARY_PATH, TNSNAMEs etc... it's a lot easier just to source in the profile. Otherwise you can just extract the variables you need from the profile and include them in your script. The reason you'd do the latter is just to avoid having to look at "stty: not a terminal" and other ugly messages you see when running a profile. These messages don't actually hurt anything but they do make your logs look crappy.
