John Burger wrote: > > > From: "Dr. David Kirkby" <[EMAIL PROTECTED]> > > [Much elided] > > > dnl something here generates an error: > > dnl "test: ==: unexpected operator" on a Sun running NetBSD 1.6 > > if test $gsl_inc_count == 0 && test $gsl_lib_count == 0; then > > gsl_not_installed=1 > > elif test $gsl_inc_count != 2 || test $gsl_lib_count != 2; then > > gsl_incomplete=1 > > fi > > I believe that the test operator = is more portable than ==. If you're > really after numeric equivalence, there's a -eq operator that I think > is fairly portable. For what it's worth, == is also unrecognized on > Mac OS X, which has a BSD lineage as well.
Okay. Looks like the -eq might be my best bet then, as this is a numeric rather than string comparision. > A separate thing I noticed: if your variable gsl_inc_count is empty or > undefined, test won't see it - its first argument will be your > (intended) operator. For this reason, I always quote such variable > arguments to test, if there's any chance they can be empty, e.g., > > if test "$gsl_inc_count" = 0 && ... > > Historically, the really retentive thing to do is something like: > > if test x"$gsl_inc_count" = x0 && ... > > or, I suppose, for a numeric comparison this would work: > > if test 0"$gsl_inc_count" -eq 0 && ... > > Usually, though, I can't bear to write such grotesqueries. I'll try it with -eq and see if that works on all the systems I have easy access to. I've got access to other systems on Sourceforge's compile farm, but they are a bit more of a pain to use for me. Hence I decided to set up my own mini compile-farm, to test for portability issues like this. So far I have 3 Suns and a PC, all running different operating systems. I'd like to get a Dec Alpha too, as their floating point is quite fussy. -- Dr. David Kirkby, Senior Research Fellow, Department of Medical Physics, University College London, 11-20 Capper St, London, WC1E 6JA. Tel: 020 7679 6408 Fax: 020 7679 6269 Internal telephone: ext 46408 e-mail [EMAIL PROTECTED]
