> Clearly, $HOSTNAME is *not* in the environment for whatever user is > executing your cron job.
cron is a root process (I assume this means multicron-p will be executed as root?) and I am logged in as root when I successfully use the $HOSTNAME global from the command line. If I can succesfully use the $HOSTNAME global from the command line while logged in as root doesn't that suggest it is a known value? Is there a command equivalent to "env" to check all available environment variables? > Does /etc/profile contain this line? > > export HOSTNAME="$(hostname)" Yes it does. > At anyrate, this is how $HOSTNAME gets it value under DCD. I vaguely > remember having problems with multicron-p and one of my working changes > is to include this line immediately prior to the call to main(): > > PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > > Nevertheless, there is nothing wrong with your use of $(hostname), since > that is the call used to set HOSTNAME to begin with . . . Now that I have it working it's more out of curiosity to know why it isn't OK the default way. Who knows, maybe other scripts on my LRP box aren't working for the same reason. Maybe it has something to do with what Dave Douthitt mentioned: "The general answer to a question of this type (i.e., why does this command work at the command line, but not when run from cron?) is that in the environment set during the execution of a script run from cron, there are only about SIX environment variables set, and much of the environment found in a command line environment is missing. However, in using standard scripts for Dachstein, this should not be a problem - but it occurs often enough that I thought I should mention it." Any ideas on what should I check to rule this out Dave? Thanks, Paul _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
