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.

Nora

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.

Liesa

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.

Abrupt

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.) – Viscose

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.

Disaccord

Using "x$foo" (with double quotes in addition to the x prefix) instead of "$foo" has nothing to do with empty strings. It has to do with the cases where "$foo" might evaluate to something that may look like a test option like -f. – Cryptomeria

An configure script not running because of shell differences is like coming to a soapbox race with a Formula-1 car. – Articulate

@Articulate I don't really get the analogy that I wrote almost ten years ago there. But it's clear that if your configure script is screwed because of a shell difference, how can it be expected to do the job smoothing a build process of a complex program, in the face of numerous other system differences. – Disaccord

@Disaccord yep you are absolutely right. I built my autotool chain around tons of bash scripts called by the m4-configured, generated Makefile, because I certainly know that its usecase won't go beyond archlinux or alpine linux. So I just turned your analogy around 180 degrees saying: If someone wants to join your Formula-1 race (sh -> bash), it is perfectly possible even with a soapbox car. But not the other way round (bash -> sh). OSX users can easily change their login shell. Formula-1 is not backwards compatible, but Autotools is for a good reason! – Articulate

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

Wisdom

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. – Liesa

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

Hosey