don't worry about it
There are always tricks to things we are new to. I'll give you a few pointers on how I write automated scripts (many will think some of it too much, but I don't think there is such a thing).
I take chrism's "full path" suggestion a little further among other things.
First thing in the script, I identify the logfile:
This way, everything in the script can use it.
Second, I create a "logEntry" function that basically just dumps out a date-prepended log entry. Very nice and handy for when you need to know specifics about when the log entries were written:
while [ "x$1" != "x" ]; do
echo "`date \"+%F %H:%M\"`: $1" >> $LOGFILE
shift 1 || break
Easy to use, just say what you want to say:
logEntry "This thing doesn't work at all"
which looks like
2009-02-20 10:48: This thing doesn't work at all
Next, I write a function whose whole purpose is to find which
. If it succeeds, it sets "WHICH" to be the full path to the which
command. If it fails, it exits the script after writing a log file entry:
# see if it's in any usual place
for whichloc in /usr/bin/which /bin/which /usr/local/bin/which; do
if [ -x "$whichloc" ]; then
# we found it, so we exit the function and move on
# we haven't found it. see if it's in the path now
WHICH=`which which 2>&1`
# check the exit code
if [ $? != "0" ]; then
# we cannot find which, terminate the script
logEntry "unable to locate which"
Notice the return code check after the `which which`
call? I think checking return codes is very important. This helps to track down problems and know when the command failed, especially if the command doesn't return anything.
Next, I'm going to put variable declaractions for every binary I use in the script. However, I want to have a quick and easy way to check whether these assignments worked or failed, so I write a quick function just for testing the return values of these:
if [ $? != "0" ]; then
logEntry "Cannot find command '$1'"
Before defining the command paths, I need to call findWhich
, but then I can check for any binary/command I use:
EGREP=`$WHICH egrep` ; canWeFindIt egrep
PHP=`$WHICH php` ; canWeFindIt php
LS=`$WHICH ls` ; canWeFindIt ls
This way, you are guaranteed that all binaries used in the script are valid and installed.
Next, I mark the main part of the script, just for fast visual reference:
And now start doing all the normal things you would. Typically if you don't want the output of a binary/command (or don't need it), it is good to dump it to /dev/null:
$PHP ./script.php >> /dev/null 2>&1
If you don't know the 2>&1 part, this is very handy. As you know there are two output streams: standard out, and standard error. Standard out is 1 and standard error is 2. This command basically tells the script to route all stderr output into stdout. The reason for this is because the >> /dev/null
only catches stdout, not stderr.
Here is an example:
If you issue the "which ls" command, it will echo something like "/bin/ls". If you add the >> /dev/null
, as "which ls >> /dev/null", it will return nothing. But, if you change ls
to something random letter combo that is definitely not a binary, like "which fdsasdfdsas >> /dev/null", notice now we DO have output, and it was not dumped into /dev/null. Because it is stderr output. If you add our handy dandy output stream redirection: "which fdsasdfdsas >> /dev/null 2>&1"
Very nice to keep unwanted output from log files and such when doing script automation.
Anyway, I hope these things help you and if not, maybe I taught you something. If not, maybe I'll teach something to someone else who reads this.