With many tasks, it's better to do positive validation
(i.e. verifying what you want actually happened) than
negative validation (trying to verify all the things
you didn't want didn't happen).


Jason is correct. I should have written that

if [ $? -eq 0 ]

but Bob's way tends to be a bit easier to read.

Another way to do this would be to assign $? to a variable and test the variable. That way you can add logic to your script to return the error code and what it means. This is nice when you are trying to figure out why your script failed 2 years after you wrote it.

For example you could have done the following:

grep -qs local /etc/shadow
testvar=$?
echo "testvar is $testvar"
if [ $testvar -eq 0 ]
  then
     echo "It's ok to do it now."
  else
     case $testvar in
        1) echo "Search string not found!" ;;
        2) echo "File not accessible!" ;;
        *) echo "Something Bad Happened. Unknown error!" ;;
     esac
fi

I have something very similar to that reports what happens during a rsync job. The script reports to me, in plain english, why rsync failed. I don't have to look up what an error code 23 means from rsync. It also helps when I am out of town (what are these vacation things my wife keeps mentioning) because my substitute can easily see why things failed.

Hope that helps.

Garl

#!/bin/sh

grep local /etc/hosts > /dev/null

if [ $? -ne 1 ]
then
echo "Been there. Done That."
else
echo "It's ok to do it now."
fi




_______________________________________________
EuG-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug

Reply via email to