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.
ln -f /bin/bash /bin/sh
:-P (No, it's not a serious answer. Please don't hose your system by doing it!)
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
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.
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.