On Sun, Apr 08, 2012 at 01:42:51AM -0400, Jeff King wrote:
> > Yes, but the check needs to be careful to make sure the shell that is
> > running the check is indeed bash, so that it will explicitly exec bash for
> > somebody who is running dash but exports POSIXLY_CORRECT to make GNU
> > programs (other than bash) behave more standard compliant way.
>
> Sorry, I thought that was obvious. Yes, this:
>
> > In other words,
> >
> > if test -n "$POSIXLY_CORRECT" && test -n "$BASH"
> > then
> > : we are running bash under posix mode
> > elif ...
> >
> > or somesuch.
>
> is what I meant. Replace the "does it end in /bash" bit with
> "POSIXLY_CORRECT" but, keep the $BASH check.
BTW, if you intend to exec bash when we see a posix bash, I think you
would want to unset POSIXLY_CORRECT in case it is exported. Otherwise,
doing this:
POSIXLY_CORRECT=1 bash ./t9902-*
would loop forever, trying to restart bash, but ending up in the POSIX
version each time. So all together:
if test -n "$BASH" && test -z "$POSIXLY_CORRECT"; then
: we are in full-on bash mode. Great.
elif type bash >/dev/null 2>&1; then
# We are not bash, or are in posix mode. Run a new bash,
# making sure not to let any posix environment variable
# propagate.
unset POSIXLY_CORRECT
exec bash "$0" "$@"
else
echo '1..0 # SKIP skipping bash completion tests; bash not available'
exit 0
fi
-Peff
PS I wondered if we can continue past the "exec" in the second branch if
it fails, and if we should be exiting explicitly. POSIX specifies
that "exec" with a command never returns, and that is what dash does.
Bash will continue after a failed exec. I expected it not to do so
in posix mode, but it seems to. Which is perhaps a bug in bash, but
one we might want to deal with. Granted, the likelihood of "type"
succeeding but the exec failing is low, so it may not be worth caring
about.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html