[prog] bash: string comparisons in conditionals

Conor Daly c.daly at met.ie
Wed Apr 21 11:27:01 EST 2004


On Tue, Apr 20, 2004 at 02:58:52PM +0200 or thereabouts, Riccarda Cassini wrote:
> Hi, thanks for taking the time, Jimen!
> 
> 
> > >  null == undefined == not initialized == not existing :=
> > >                                 variable doesn't exist at all
> > >                                 or hasn't been assigned anything yet
> > >
> > >  empty := string that doesn't contain anything (zero-length)
> > >
> > >  zero  := numeric value '0'
> 
> > >Last question: are there any circumstances in which [ "$a" = "" ]
> > >(or [ "x$a" = "x" ] for that matter) would not give the same result as
> > >[ -z "$a" ] ?

a = "test test"

> That's what I wanted to hear :-)  so, I can choose my favorite version
> (which is -z, 'cos it's most compact, and seems least prone to trouble)
> 
> 
> > >Sub-question: are quotes around the $a recommended in the latter case,
> > >too?
> > 
> > It depends.  My manual page says -z takes a string as argument.  So
> > whether you need qoutes depends on whether 'a' is a string or something
> > else.  I.e. if 'a' is a number, then yes.

I beg to differ here.  In bash, the args are handed to the tests as strings
(just as they are to a C program or a perl script).  The program then treats
the args as it requires them.  Eg. [ $a -eq 2 ] will treat 'a = x' as an
error because it's not an integer. Putting $a in quotes means it gets
treated as a single argument.  eg.

a = "test test"

[ -z $a ]

fails with:  "[: test: binary operator expected" but 

[ -z "$a" ]

works.
 
> number vs. string argument relates here.  I thought the quotes
> primarily serve to prevent the argument from disappearing altogether
> (syntactically) if it's empty.

And to preserve the argument as a single unit.
 
> a problem with $a being empty (sorry for bringing up perl all the time,
> I don't have many alternatives yet to refer to...).  As far as I know,

Always useful to give a handle on your current understanding...

> In bash, on the other hand, it seems to me, that variable expansion
> happens *before* the code is passed to the parser.  So, assuming that
> $a holds the value 'test', the parser would see the literal string
> 'if [ test = "" ]' (for the above example).  Or, if $a is empty:
> 'if [  = "" ]'.  At least, that's what I figured from the error
> messages I got. I could be totally wrong, though.

That sounds about right.
 
> there's no problem with [ -z $a ] 

Just the one, see above.

Below is a brief bash script that uses all the tests I can think of for
various values of $a 

##############################################################
#!/bin/bash
# Name: test.sh
# Purpose: run various tests on different args
# Author: Conor Daly
# License: GNU Public License (GPL)

testfn() {
echo "\$a = $a"

if [ $a -eq 0 ]; then
 echo "zero"
fi

if [ $a -eq 1 ]; then
 echo "one"
fi

if [ -z $a ]; then
 echo "short"
fi

if [ -z "$a" ]; then
 echo "short (quoted)"
fi

if [ ! $a ]; then
 echo "undefined"
fi

if [ ! "$a" ]; then
 echo "undefined (quoted)"
fi

if [ $a = "" ]; then
 echo "empty"
fi

if [ "$a" = "" ]; then
 echo "empty (quoted)"
fi

if [ "X$a" = "X" ]; then
 echo "empty (X)"
fi

echo "done"
echo
}

testfn $a

a=""
testfn $a

a=x
testfn $a

a=1
testfn $a

a="test"
testfn $a

a="test test1"
testfn $a
##############################################################

Conor
-- 
Conor Daly,                   Please avoid sending me 
Met Eireann, Glasnevin Hill,  Word or PowerPoint attachments.
Dublin 9, Ireland             http://www.fsf.org/philosophy/no-word-attachments.html
Ph +3531 8064276 Fax +3531 8064247


**********************************************************************
This e-mail and any files transmitted with it are confidential 
and intended solely for the addressee. If you have received
this email in error please notify the sender.
This e-mail message has also been scanned for the
presence of computer viruses.
**********************************************************************



More information about the Programming mailing list