tags:

views:

40

answers:

3

why does:

#!/bin/bash
wtf=false
if [ $wtf ] || [ ! -f filethatexists.whatever ]
then
 echo "WTF1"
fi
if [ ! -f filethatexists.whatever ]
then
 echo "WTF2"
fi

print:

WTF1

instead of nothing? It is especially perplexing that the second form works as expected and the first not.

+1  A: 

The basic test

[ $wtf ]

tests whether the string in the middle is empty or not.

Since $wtf is 'false', the test returns true (because 'false' is not the same as '') - and hence you get WTF1 as the response.

Try with:

wtf=''

As pointed out by Gordon Davisson (and Dennis Williamson), it is a good idea to be careful with strings that you are testing. Indeed, I should have stated that I would always use [ -n "$wtf" ] or [ -z "$wtf" ] to test whether a variable is set, because that was necessary when I was learning shell, once upon a quarter century ago. I've had counter stories from Bash afficionados that you don't have to worry about it in bash - however, I think the code here provides a counter-example that in fact you do still have to worry about it.

So, some best practices:

  • Enclose tested variables in double quotes, or
  • (In Bash), use [[ $wtf ]] which does know how to handle the variable expansion.
  • Use the -n or -z tests to test for non-empty or empty values.

There can be exceptions to the rules - but you will not go far wrong following them.

Consider the code:

wtf="1 -eq 0"
 [  $wtf  ]  && echo "WTF0"
[[  $wtf  ]] && echo "WTF1"
wtf="false"
 [  $wtf  ]  && echo "WTF2"
[[  $wtf  ]] && echo "WTF3"
wtf=""
 [  $wtf  ]  && echo "WTF4"
[[  $wtf  ]] && echo "WTF5"
wtf="false"
 [ "$wtf" ]  && echo "WTF6"
[[ "$wtf" ]] && echo "WTF7"
wtf=""
 [ "$wtf" ]  && echo "WTF8"
[[ "$wtf" ]] && echo "WTF9"

That produces:

WTF1
WTF2
WTF3
WTF6
WTF7

with both bash and ksh (as found on MacOS X 10.6.4, when run with 'bash testcode.sh' or 'ksh testcode.sh'). A real Bourne shell (if you can still find such a thing) would object to the double-bracket operations - it would not be able to find the command '[[' on $PATH.

You can extend the testing to cover more cases ad nauseam.

Jonathan Leffler
ok, makes sense. The syntax highlighting made me thing that booleans were a given. Guess i expected too much.
i30817
Actually, it's even weirder than that -- if $wtf has any spaces in it, it'll be evaluated as an expression. Try it with `wtf="1 -eq 0"` and `wtf="1 -eq 1` to see the effect. For even more comedy, try `wtf="1 -eq"`
Gordon Davisson
Test 4/5 is a duplicate of test 8/9. I think you meant to do 4/5 without quotes around the variable (but the result is the same - nothing is echoed). Also, test 0/1 altered by quoting the variable doesn't evaluate the `1 -eq 0` so both bracket types evaluate to true (as in test 2/3). Interestingly, in Bash and ksh, `[ '' ]`, `[[ '' ]]` and `[ ]` each work, and return false, however `[[ ]]` produces an error.
Dennis Williamson
A: 

if [ $wtf = true ] || [ ! -f . .

0x90
or even "if [[ $wtf == true ]] || [ ! -f ..."
dimba
+1  A: 

Here's a handy little trick:

wtf=false
if $wtf || [ ! -f filethatexists.whatever ]

In this form, the contents of the variable are executed and the return value determines whether the test passes or fails. It happens that true and false are Bash builtins that return the appropriate value.

Dennis Williamson