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

Chris Jester-Young
You can downvote me all you like; it just proves you have no sense of humour. :-P
Chris Jester-Young

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" "[email protected]"
Ted Percival
The problem is that sometimes Configure scripts require syntax not supported by Bourne shell. The Configure script is broken, but that's life in the software industry. At that point, you need to persuade Configure to run with the correct shell - and that requires CONFIG_SHELL as I indicated.
Jonathan Leffler
+3  A: 

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.

Jonathan Leffler
+1  A: 

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

William Pursell
Just FYI, there are indeed situations where /bin/sh is a problem. On AIX, for example, using /bin/sh can make a build take ages because /bin/sh handles the configure-typical tests very, very slowly. (Might be fixed in newer versions, it's been some time since I encountered that particular problem.)