[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:
[diff]
> > @@ -579,7 +579,7 @@
> > m4_defun([_AS_PATH_SEPARATOR_PREPARE],
> > [# The user is always right.
> > if test "${PATH_SEPARATOR+set}" != set; then
> > - echo "#! $SHELL" >conftest.sh
> > + echo "#! /bin/sh" >conftest.sh
> > echo "exit 0" >>conftest.sh
> > chmod +x conftest.sh
> > if (PATH=".;."; conftest.sh) >/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]
bye,
Andreas