autoconf using sh, I need SHELL=BASH, how do I force autoconf to use bash?

Question

I'm running autoconf and configure sets SHELL to '/bin/sh'. This creates huge problems. How to force SHELL to be '/bin/bash' for autoconf?

I'm trying to get this running on osx, it's working on linux. Linux is using SHELL=/bin/bash. osx defaults to /bin/sh.

Answer 1

I have similar problems on Solaris with GCC - and I use the 'standard' technique:

CONFIG_SHELL=/bin/bash ./configure ...

(Or, actually, I use /bin/ksh, but setting the CONFIG_SHELL env var allows you to tell autoconf scripts which shell to use.)

I checked the configure script for git and gd (they happened to be extracted) to check that this wasn't a GCC peculiar env var.

Answer 2

What are the "huge problems"? autoconf works very hard to generate a configure script that works with a very large percentage of shells. If you have an example of a construct that autoconf is writing that is not portable, please report it to the autoconf mailing list. On the other hand, if the problems you are experiencing are a result of your own shell code in configure.ac not being portable (eg, you're using bashisms) then the solution is to either stop using non-portable code or require the user to explicitly set SHELL or CONFIG_SHELL at configure time.

It sounds like the problem you are experiencing is in the environment of the user running configure. On Linux, your user has SHELL set to /bin/bash, but on OS X it is set to /bin/sh. The configure script generated by autoconf does some initial tests of the shell it is running under and does attempt to re-exec itself using a different shell if the provided shell lacks certain features. However, if you are introducing non-portable shell code in configure.ac, then you are violating one of the main philosophy's of autoconf -- namely that configure scripts should be portable. If you truly want to use bashisms in your shell code, then you are requiring your user to pass SHELL=/bin/bash as an argument to the configure script. This is not a bug in autoconf, but would be considered by many to be a bug in your project's build.

Answer 3

Autoconf is supposed to solve portability problems by generating a script which can run "anywhere". That's why it generates bizarre code like:

if test X$foo = X ; then ...   # check if foo is empty

rather than:

if [ "$x" = "" ] ; then ...

That kind of crufty code probably once allowed these scripts to run on some ancient Ultrix system or whatever.

An configure script not running because of shell differences is like coming to a Formula-1 race with 10 liters of gas, and three spare tires.

If you're developing a configure script with Autoconf, and it is sensitive to whether the shell is Bash or the OSX shell, you are doing something wrong, or the Autoconf people broke something. If it's from you, fix whatever shell pieces you are adding to the script by making them portable.

Answer 4

Where is SHELL being set to that? What is being run with /bin/sh when you want /bin/bash?

configure scripts are meant to run anywhere, even on the horribly broken and non-Bash shells that exist in the wild.

Edit: What exactly is the problem?

Another edit: Perhaps you'd like the script to re-execute itself, something like this. It's probably buggy:

if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then
    exec /bin/bash -c "$0" "$@"
fi

Answer 5

ln -f /bin/bash /bin/sh

:-P (No, it's not a serious answer. Please don't hose your system by doing it!)