Re: autoconf 2.52f and OS/2

[Tim Van Holder]

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

On DOSish systems, there is no such thing as /bin.  And creating
a /bin directory (with a sh.exe in it) on each drive is nonsense.
So DJGPP's bash handles #! by looking it up on the path if it is
not found.  So '#! c:/foo/bar/xyzzy' will invoke the xyzzy program
in c:/foo/bar, but so will '#! /usr/local/bin/xyzzy' (provided
c:/foo/bar is in the path).  So if /bin/sh is used, there is not
usually any problem; but since this tests basically unsets PATH,
our bash will be unable to find sh anywhere, and fail.

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

That's not the point.  Since you posted this patch, OS/2 shells
wouldn't fail and cause ':' to be used anyway.

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

I said 'bad' shell, not 'Microsoft' :-P

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

?
No error messages are printed (in fact, configure never even tells
you it checked for the pathsep, let alone what it finds).

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

Ouch - that is indeed braindead behaviour; there is no good reason
for SHELL to ever refer to a non-Unixy shell.

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

That would be acceptable, as DJGPP's config.site sets CONFIG_SHELL
to SHELL anyway.  Unfortunately, config.site is loaded after this
test.

I've decided this should stay a local patch for DJGPP; I'll try to
get our bash changed to handle this case better.