[prog] bash: string comparisons in conditionals

Riccarda Cassini riccarda.cassini at gmx.de
Thu Apr 22 01:05:37 EST 2004


Hi Jimen and Conor!

Jimen Ching wrote:
> Another example is null and 0.  In C++, the following can be read as:
> 
>     if (ptr != 0) // Test for a null pointer.
>         ;
> 
> Also, I've just re-read the question.  My response applies to null, empty
> and 0.  I noticed you also had 'undefined', 'not initialized' and 'not
> existing'.  These later terms have a very specific definition.
> Especially for C and C++.  And most other languages usually have a
> specific definition of these terms as well.  The last term is usually
> spelled as 'non-existing', rather than 'not existing'.  You should never
> inter-change these words.  Otherwise, you'll like get confusion as a
> result.
> 
> One other term I should mention is--'not defined'.  At least in C/C++,
> this is different from 'undefined'.  Both specifies a behavior of some
> language construct.  'Not defined' says the construct behavior was not
> specified by the standard.  While 'undefined' says the construct behavior
> can be anything (which is specifically specified by the standard).
> 
> To the programmer, these two terms are basically the same.  But to a
> compiler writer, their meaning is very different.

This whole terminology thing obviously is far more diverse than I
thought at first - and usage apparently differs from language to
language...   I guess it's probably a good idea to stick with one
set of terms for every language.

I don't know much about C/C++, yet ('hardly anything' would actually be
the more honest wording), but there will be the time when I get around
to those as well :-)  I'll remember to reread your remarks then...

> 
> You might want to use the term 'unset', instead of 'undefined'.

Another term on the list of items to choose from :-)
'unset' seems to be shell-speak - at least in perl the term 'undefined'
appears to be more commonly used, AFAIK  (there even is a specific
reserved token 'undef').

> 
> As for why -z accepted an unset variable.  I can only assume it's because
> of the implementation.  With a binary operator, a missing operand makes
> the test look like a unary operator or an unset operand.  Without knowing
> which case it is, the shell shouldn't make any assumptions.  Thus it
> errors out.  While with a unary operator, a missing operand will still
> make it a unary operator.  So the shell can safely assume the operand was
> unset.

Sounds like a clever explanation. Makes sense.


> >        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 :-)
> 
> This is actually a trait of a good programmer.  So don't be sorry.

Thanks.  I'm currently trying to cut down on saying sorry... don't you
think I'm doing rather well - not a single time, so far! ;-)



Conor Daly wrote:
> 
> >>>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"

Um, how? - Or do you mean with unquoted $a ?

I seem to be getting the same correct results for all kinds of input
with all of the following variations:

  [ ! "$a" ]
  [ -z "$a" ]
  [ "$a" = "" ]
  [ x"$a" = x ]
  [ "x$a" = x ]
  [ "x$a" = "x" ]

(that makes [ ! "$a" ] my new favorite, btw)

 
> > 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.

Good point!

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

I was about to put together something like this myself... thanks for
doing it for me :-)



With your helpful explanations, and some more experimenting on my own,
I think I now have a working knowledge of how bash operates, so I can
write scripts that won't immediately break due to some unforeseen
circumstance or edge case...

Thanks a lot, guys, you're wonderful!

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