[Top][All Lists]

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

Re: autoconf 2.52f and OS/2

From: Andreas Buening
Subject: Re: autoconf 2.52f and OS/2
Date: Mon, 28 Jan 2002 19:02:35 +0100

Tim Van Holder wrote:


> > @@ -579,7 +579,7 @@
> >  [# The user is always right.
> >  if test "${PATH_SEPARATOR+set}" != set; then
> > -  echo "#! $SHELL" >
> > +  echo "#! /bin/sh" >
> >    echo  "exit 0"   >>
> >    chmod +x
> >    if (PATH=".;."; >/dev/null 2>&1; then
> This breaks the check on DJGPP; if /bin/sh is used, the
> test never detects the ';'; it needs $SHELL(*).

Sounds strange. Which shell do you use if /bin/sh doesn't work?

> While using PATH_SEPARATOR=: isn't harmful for configure
> (as DJGPP's bash transforms PATH to match PATH_SEPARATOR),

OS/2's ported shells don't do this.

> it does break make rules that use @PATH_SEPARATOR@, as
> the environment won't have PATH_SEPARATOR set to ':' and
> therefore path searches won't work as expected.

Of course.

> In any case, if anything goes wrong with the test due to
> a bad shell, it will detect ':', which will very likely be

or it will hang. ;-)

> the correct result.  On DOSish systems, which is what this
> test is intended for, '/bin/sh' is much more likely to fail
> than $SHELL.

It depends. The message "/bin/sh not found" is a much more obvious
error message than a failing make or even a linked executable
that doesn't work.

> If the problem is that SHELL might not be set,
> then ${SHELL-/bin/sh} would solve that better.  And if SHELL
> is not a Unixy shell, than that is a user error IMHO.
> Andreas, what exactly was the problem on OS/2?  What is SHELL
> set to (and is this a user setting, or forced by the OS)?

The concrete problem was that the bash port I was using as
interactive shell sets SHELL to cmd.exe which is nonsense.
But aside from this "feature" I would prefer the "make"
philosophy to completely ignore the SHELL environment variable.
This is what CONFIG_SHELL is for. Using ${CONFIG_SHELL-/bin/sh}
would be more consistent than referring to SHELL at this point.

[shell bug]


reply via email to

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