Mail Archives: djgpp-workers/2002/01/30/09:30:22
On Wed, 2002-01-30 at 13:40, Eli Zaretskii wrote:
>
> On Tue, 29 Jan 2002, Tim Van Holder wrote:
>
> > The reason things fail is that our bash handles '#! /bin/sh'
> > by looking for sh along the path, and PATH is effectively
> > reduced to '.' for the purpose of this test.
> > I would suggest that bash should always tack on $DJDIR/bin
> > and/or dirname(argv0-of-bash) to PATH for the purpose of
> > these lookups (or look in $DJDIR/bin first for any /[s]bin,
> > /usr/[s]bin or /usr/local/[s]bin paths).
>
> It sounds wrong to me to make such a global change just to satisfy an
> obscure test in a single package. The current logic of handling
But that test ends up in every single configure script generated by
autoconf, so it has far-reaching consequences.
> /bin/sh worked for us since v2.01, and we never had any problems. Why
> change it now?
>
> I'd rather try to convince Autoconf maintainers to undo the change
> they did for OS/2, and solve the OS/2 problem in some other way. For
> example, they could set SHELL to /bin/sh for OS/2 only. No one said
> DJGPP has to be broken for OS/2's sake.
In general, I agree, and I did try to have the patch undone. One is
that they do not want to rely on $SHELL (which is why CONFIG_SHELL
was introduced in the first place). Another is that /bin/sh is an
absolute path, so PATH should have NO bearing on whether it's found or
not. That is why I suggested bash be changed to always look in
$DJDIR/bin for those lookups (as that directory is our equivalent of
/bin, /usr/bin, etc.).
I'll probably keep using $SHELL as a local patch; as an alternative,
I'll also try to get the loading of config.site moved up, so that the
test can use ${CONFIG_SHELL-/bin/sh} (currently, config.site gets loaded
after this test, so if CONFIG_SHELL is set there, it has no effect on
the test).
- Raw text -