autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do I make a portable test??


From: Eric Siegerman
Subject: Re: How do I make a portable test??
Date: Fri, 14 Feb 2003 12:39:23 -0500
User-agent: Mutt/1.2.5i

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

> > I bet the Solaris box has bash installed -- and as /bin/sh too!
> 
> The Solaris box does indeed have bash installed, but it is NOT
> /bin/sh. /bin/sh is unchanged from the default Sun installation. I do
> however have a /usr/local/bin/test, which is possibly what is being
> used on the Sun and not on the other system.

That's one possibility.  Try renaming it first, and see if the
"=="'s still work; they might well do.

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

> Someone else wrote that bit of code on a Dec Alpha, which runs on his
> system, although I don't know what OS he runs on it - probably Linux
> though. I know he uses the bash shell, but whether that is /bin/sh on
> his machine I have no idea.

Even if not, the LINENO stuff could be involved there too.

> > By "(tcsh shell)" I presume you mean it's your login shell.
> > That's irrelevent; what matters is the one named in the script's
> > "#!" line.
> 
> Yes, tcsh is my login shell - I keep meaning to change there seems to
> a lot to suggest scsh/tcsh are not a good choice.

Aside: I wouldn't worry too much about it.  Csh and its
descendents are notoriously lousy for writing scripts in [1], but
for interactive use, as far as I can see it's purely a matter of
taste.  (I can't comment on scsh, though; never heard of it.)

> Would I be right in assuming there is some sense in temporarily
> changing /bin/sh to point to different shells in order to check
> portability? 

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

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?)

[1] See Tom Christiansen's "Csh Programming Considered Harmful":
        http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
        - Leslie Lamport




reply via email to

[Prev in Thread] Current Thread [Next in Thread]