[prog] bash: string comparisons in conditionals

[Riccarda Cassini]

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'
> >
> >Is that correct?
> 
> There's no one true definition for any of these.  In some contexts, one
> can be substituted for another.

I see... you mean one can say things like "null" to mean "null-string"
and so on... Doesn't necessarily make it easier to know what precisely
people are talking about, but I guess that's natural languages...


> >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" ] ?
> 
> An empty string has length zero, so no.

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.

sorry for insisting and coming up with more questions... (but don't
feel obliged to respond, of course).  I'm not sure I understand how
number vs. string argument relates here.  I thought the quotes
primarily serve to prevent the argument from disappearing altogether
(syntactically) if it's empty.

What had me stumped particularly was, that if you write [ -z $a ] and $a
is empty or undefined, you don't get a syntax error as in [ $a = "" ].
>From what I thought I had understood about how the shell handles
variable expansion, I would've predicted that the expanded string
'[ -z ]' is equally subject to parsing issues as the '[ = "" ]', which
gives me "./test.sh: [: =: unary operator expected" (which I interpret
to mean that the parser stumbles across the binary operator '=',
because, due to the missing $a, there can only appear a unary operator
in this position - [sorry, typical german nested sentence construction
style... hope you can still follow]).  With '[ -z ]', in contrast, the
parser seems to have no problem with the missing argument after -z.

Well, I think I still haven't quite got my head around how and when the
shell expands, parses and executes the code.

Maybe I should elaborate: 

In perl, for example, you can write 'if ($a eq "")' without there being
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,
this is due to the fact that this code fragment gets parsed into some
internal representation before the actual value of $a is known.  Some
space is being set aside to hold the variable's final value - so
syntactically it doesn't matter, whether it's emtpy (i.e. the parser
always sees '$a' literally).

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.

So, essentially, I'm just wondering whether my theory about how
the shell behaves is correct. Or, put differently, if there's any
explanation for why there's no problem with [ -z $a ] when $a is
undefined. Sorry for being repetitive and long-winded [*] - I'm always
trying to understand the basic principle behind things, so I can work 
out the solution myself next time (ideally :-)

Riccarda


[*] just realised that this is the fourth time I said sorry, so maybe I
should add: I'm sorry for being sorry all the time... ;-)



-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl