Re: How do I make a portable test??

[Dr. David Kirkby]

Eric Siegerman wrote:
> 
> On Fri, Feb 14, 2003 at 09:39:21AM +0000, Dr. David Kirkby wrote:
> > Thanks, I assume then in this case I should be using -eq, since I am
> > comparing the numeric values of something - whether it is 0 or has
> > been incremented by one or two.
> 
> Yup.  The difference tends to show up in things like this:
>         1 -eq 01        # True (duh)
>         1 = 01          # False
>

In fact I gave up trying to use numeric numbers, as these two lines,
which were supposed to be incrementing the numeric value of
gsl_inc_count were not.

AC_HAVE_HEADERS(gsl/gsl_sf_ellint.h,[gsl_inc_count=$(($gsl_inc_count +
1))])
AC_HAVE_HEADERS(gsl/gsl_sf_bessel.h,[gsl_inc_count=$(($gsl_inc_count +
1))])

In fact, I only just realised that was not working on my Sun either,
so that plan went out the window. (Other methods have worked on the
Sun okay). The method I'm now trying to use is a bit messier, but I
thought would be more relieable (but see my other post). 

> Another possibility is that it's autoconf's LINENO stuff muddying
> the waters:
>   - You type: "configure"
>   - The script runs in /bin/sh, a vanilla Bourne shell
>   - Early on, the configure script realizes that it's running in
>     a shell that doesn't support $LINENO, and looks for an
>     alternate shell that does
>   - It finds one, and re-executes itself in that shell
>   - The shell it found was bash, which supports "=="; if you put
>     /bin first in your path (try it temporarily as a test),
>     configure would probably find /bin/ksh instead, and the
>     "=="'s would produce the familiar diagnostics
> 
I believe I have seen that behaviour. Sometimes configure seems to
fail, then starts again and works. I've also seen configure run, then
after typing make, configure runs again and somewhere in the output I
see bash mentioned. (This is on the Sun Ultra 80/Solaris 9 box, which
is the best of my n computers. The others are used just for testing
portability issues like these.)

> > I think I might delete
> > that, as there seem no way I can find out where it is from. It's a
> > binary, but does not respond to -v, -V, -h or any other switch I can
> > think of. Hence its origin is unknown. Perhaps best deleted.
> 
> You can also try "strings /usr/local/bin/test | more" and look for
> any identifying information, e.g. copyrights.

A bit late for that now. I could restore it from tape, but I did an rm
rather than an mv.

> Could do, but it's easier than that.  Just type "ksh configure [opts]"
> instead of plain "configure [opts]".

Cheers, that is handy to know. 
 
> Either way, be aware that the $LINENO stuff might mess you up by
> running the script in a shell other than the one you asked for.
> One possible hack to at least learn whether that's happening would
> be to edit this into the configure script at some point after the
> LINENO machinations:
>         ps | grep "$$" >/dev/tty
> 
> Alternatively, send that command's output to config.log.  (Is there
> a sanctioned way to do so?)

> A distributed system is one on which I cannot get any work done,
> because a machine I have never heard of has crashed.

I hope not. The code is question is designed to run on a distributed
system!!
-- 
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 address@hidden