[prog] bash: string comparisons in conditionals
Riccarda Cassini
riccarda.cassini at gmx.de
Mon Apr 19 17:02:13 EST 2004
Hi all,
me again, with another bash question that's hopefully easy to answer.
I'm currently trying to get my head around the nitty gritty details of
shell tests and comparisons.
When looking at other people's scripts, I sometimes see constructs like
if [ "x$1" = "x" ]
I understand that adding identical substrings to both sides of the
comparison doesn't really change the outcome of the test, but why is
this necessary? Or, if it isn't necessary, why are many people (which
I assume to be experts) using constructs like these? Wouldn't "" = ""
be seen as equal, too, if $1 expands to nothing? Empirical evidence
suggests that the latter holds true...
Anybody care to let me in on this secret little unix mystery that
everyone else seems to knows about... :-) I haven't seen any mention
of it in the docs that I've looked through so far - only rather
elaborated discussions of why the quotes are recommended.
Does this have to do with some subtle difference between $1 being null
(undefined?) versus empty?
Btw, what's the precise terminology usage anyway (in shell-speak) for
null, undefined, initialized, existing, empty, zero (anything else I'm
not aware of?)?
My current understanding is that
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?
Through trial and error I've found out that you get a syntax error at
runtime for [ $1 = "" ] if $1 is empty/null, i.e. when you omit the
quotes *and* the 'x' around the $1. (Seems logical, if one assumes
that the internally expanded string 'if [ = "" ]' is somehow literally
being fed through the shell's parser again...)
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" ] ? Sub-question: are quotes around the $a recommended in
the latter case, too? It seems that they are not *required*, at least,
though I don't see why: Applying the same (assumed) parsing logic
from above, why should the internally expanded string [ -z ] be
syntactically any less invalid than [ = "" ] ? Doesn't a unary
operator like -z need one argument, when the binary operator '=' needs
two??
I think I better stop here for now - I seem to be generating more and
more questions as I write ;-)
Thanks in advance,
Riccarda
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
More information about the Programming
mailing list