With many tasks, it's better to do positive validationJason is correct. I should have written that
(i.e. verifying what you want actually happened) than
negative validation (trying to verify all the things
you didn't want didn't happen).
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