I’m running a script fine from the command line, but it fails when put into a cronjob. I’ve narrowed it down to specifically a problem with testing for file existence with [ -e “name” ]. With this running in Ubuntu 32-bit desktop, I can write the following script and have it work when called from the command line:
#!/bin/bash
# define statements
IMPORT="/home/${USER}/data_imports/fitb"
ARCHIVE="${IMPORT}/archive"
declare -a CENTERS
CENTERS[0]="ct"
CENTERS[1]="ny"
len=${#CENTERS[*]}
RUNDATE=`date --date=yesterday +"%m%d"`
ARCHIVEDATE=`date --date=yesterday +"%Y_%m_%d"`
i=0
while [ $i -lt $len ]; do
if [ -e "${ARCHIVE}/fitb_${ARCHIVEDATE}_${CENTERS[i]}.csv" ]
then touch ~/data_imports/fitb/shell_${i}.rn
fi
let i++
done
If I comment out the lines “if”, “then”, & “fi” after putting the touch command on its own line, the while loop runs fine in a cronjob. If I put the if test back in, I get nothing. To test if it’s even being picked up by the cron daemon, I moved the touch command to the line after the shebang, so it’s the first command that runs. This fails to produce anything. I know the files tested for with -e are in the proper location, with global rx permission. Could it be that -e needs to be +w for the test to succeed?I thought it could be due to the fact that variables aren’t inhereted by subshells (of which, to my understanding, the tst is a sort), but if that were the case, I would think the CLI invocation would fail as well.
You seem to be relying on ${USER} being defined. That’s not the case when running as a cronjob.