X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Subject: Re: Small bash issue with #! handling
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1020130144014.17919M@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020130144014 DOT 17919M AT is>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0.1 
Date: 30 Jan 2002 15:29:17 +0100
Message-Id: <1012400962.3589.11.camel@bender.falconsoft.be>
Mime-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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