autoconf utilisant sh, j'ai besoin de SHELL = BASH, comment forcer autoconf à utiliser bash?

Question

J'exécute autoconf et configure configure SHELL sur '/ bin / sh'. Cela crée d'énormes problèmes. Comment forcer SHELL à être '/ bin / bash' pour autoconf?

J'essaie de faire fonctionner ceci sur osx, cela fonctionne sous linux. Linux utilise SHELL = / bin / bash. Par défaut, osx est / bin / sh.

Answer 1

J'ai des problèmes similaires sous Solaris avec GCC - et j'utilise la technique "standard":

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

(Ou, en fait, j'utilise / bin / ksh, mais la configuration de CONFIG_SHELL env var vous permet d'indiquer aux scripts autoconf le shell à utiliser.)

J'ai vérifié le script de configuration pour git et gd (ils ont été extraits) pour vérifier qu'il ne s'agissait pas d'une variable d'environnement propre à GCC.

Answer 2

Quels sont les "problèmes énormes"? autoconf travaille très dur pour générer un script de configuration qui fonctionne avec un très grand pourcentage de shells. Si vous avez un exemple de construction écrite par autoconf qui n'est pas portable, signalez-le à la liste de diffusion autoconf. D’autre part, si les problèmes que vous rencontrez sont dus au fait que votre propre code shell dans configure.ac n’est pas portable (par exemple, vous utilisez des bashismes), la solution consiste à cesser d’utiliser du code non portable ou à exiger le l’utilisateur de définir explicitement SHELL ou CONFIG_SHELL au moment de la configuration.

Il semble que le problème que vous rencontrez se situe dans l'environnement de l'utilisateur exécutant configure. Sous Linux, SHELL est défini sur / bin / bash par l'utilisateur, mais sous OS X, il est défini sur / bin / sh. Le script de configuration généré par autoconf effectue certains tests initiaux sur le shell dans lequel il s'exécute et tente de se réexécuter à l'aide d'un shell différent si le shell fourni manque de certaines fonctionnalités. Cependant, si vous introduisez du code shell non portable dans configure.ac, vous violez l’un des principes principaux de autoconf - à savoir que les scripts de configuration doivent être portables. Si vous voulez vraiment utiliser des bashismes dans votre code shell, vous demandez à votre utilisateur de passer SHELL = / bin / bash en tant qu'argument du script configure. Ceci n'est pas un bogue dans autoconf, mais serait considéré par beaucoup comme un bogue dans la construction de votre projet.

Answer 3

Autoconf est censé résoudre les problèmes de portabilité en générant un script pouvant s'exécuter "n'importe où". C'est pourquoi il génère un code bizarre tel que:

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

plutôt que:

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

Ce genre de code cruel a probablement déjà permis à ces scripts de s'exécuter sur un ancien système Ultrix ou autre.

Un script de configuration qui ne fonctionne pas en raison de différences de coque équivaut à une course de Formule 1 avec 10 litres d’essence et trois pneus de secours.

Si vous développez un script de configuration avec Autoconf et qu'il est sensible au fait que le shell soit Bash ou OSX, vous faites quelque chose de mal ou les personnes d'AutoConf ont cassé quelque chose. Si cela vient de vous, corrigez les morceaux de shell que vous ajoutez au script en les rendant portables.

Answer 4

Où se trouve SHELL? Qu'est-ce qui est exécuté avec / bin / sh quand vous voulez / bin / bash?

Les scripts de configuration sont conçus pour fonctionner n'importe où, même sur les shells horriblement brisés et non-Bash qui existent à l'état sauvage.

Modifier : quel est exactement le problème?

Une autre modification : vous voudriez peut-être que le script se ré-exécute lui-même, quelque chose comme ceci. C'est probablement un buggy:

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

Answer 5

ln -f / bin / bash / bin / sh

:-P (Non, ce n'est pas une réponse sérieuse. Merci de ne pas arroser votre système en le faisant!)