Jeff King [off-list ref] writes:
On Sat, Apr 07, 2012 at 09:25:29PM -0700, Junio C Hamano wrote:
quoted
Bash has a special case code to behave in a "posixly correct" mode, where
a lot of extensions are disabled, when invoked as "sh". Unfortunately, it
still defines BASH_* variables, including BASH, when operating in this
mode.
[...]
So we may want to be a bit more careful like this:
if test "z${BASH%/bash}" != "z${BASH}"
then
: ends with bash so we are already running bash as bash
If bash is in posix mode (including "bash --posix" and being invoked as
"bin/sh"), it will set POSIXLY_CORRECT (but not export it). Similarly,
if POSIXLY_CORRECT is set in the outer environment, it will act more
like sh. So maybe that would be a better test.
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.
In other words,
if test -n "$POSIXLY_CORRECT" && test -n "$BASH"
then
: we are running bash under posix mode
elif ...
or somesuch.
On Sat, Apr 07, 2012 at 10:41:32PM -0700, Junio C Hamano wrote:
quoted
If bash is in posix mode (including "bash --posix" and being invoked as
"bin/sh"), it will set POSIXLY_CORRECT (but not export it). Similarly,
if POSIXLY_CORRECT is set in the outer environment, it will act more
like sh. So maybe that would be a better test.
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.
-Peff
On Sun, Apr 08, 2012 at 01:42:51AM -0400, Jeff King wrote:
quoted
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:
quoted
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.