autoconf usando sh, ho bisogno di SHELL = BASH, come posso forzare autoconf ad usare bash?

StackOverflow https://stackoverflow.com/questions/161064

  •  03-07-2019
  •  | 
  •  

Domanda

Sto eseguendo autoconf e configuro i set SHELL su '/ bin / sh'. Questo crea enormi problemi. Come forzare SHELL in '/ bin / bash' per autoconf?

Sto cercando di farlo funzionare su osx, funziona su Linux. Linux sta usando SHELL = / bin / bash. Il valore predefinito di osx è / bin / sh.

È stato utile?

Soluzione

Ho problemi simili su Solaris con GCC - e utilizzo la tecnica 'standard':

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

(O, in realtà, io uso / bin / ksh, ma l'impostazione di CONFIG_SHELL env var ti permette di dire agli script di autoconf quale shell usare.)

Ho controllato lo script di configurazione per git e gd (si è scoperto che sono stati estratti) per verificare che questo non fosse un GV peculiare env var.

Altri suggerimenti

Quali sono i "problemi enormi"? autoconf lavora molto duramente per generare uno script di configurazione che funzioni con una percentuale molto grande di shell. Se hai un esempio di costrutto scritto da autoconf che non è portatile, segnalalo alla mailing list di autoconf. D'altra parte, se i problemi riscontrati sono il risultato del codice della propria shell in configure.ac che non è portatile (ad esempio, si stanno utilizzando i bashismi), la soluzione è quella di smettere di usare codice non portatile o richiedere il utente per impostare esplicitamente SHELL o CONFIG_SHELL al momento della configurazione.

Sembra che il problema riscontrato nell'ambiente dell'utente che esegue la configurazione. Su Linux, l'utente ha SHELL impostato su / bin / bash, ma su OS X è impostato su / bin / sh. Lo script di configurazione generato da autoconf esegue alcuni test iniziali della shell su cui è in esecuzione e tenta di rieseguirsi usando una shell diversa se la shell fornita non dispone di alcune funzionalità. Tuttavia, se si sta introducendo un codice shell non portatile in configure.ac, si sta violando una delle principali filosofie di autoconf, ovvero che gli script di configurazione devono essere portatili. Se vuoi veramente usare i bashismi nel tuo codice shell, allora stai richiedendo al tuo utente di passare SHELL = / bin / bash come argomento allo script di configurazione. Questo non è un bug in autoconf, ma sarebbe considerato da molti un bug nella build del tuo progetto.

Si suppone che Autoconf risolva i problemi di portabilità generando uno script che può eseguire "ovunque". Ecco perché genera un codice bizzarro come:

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

anziché:

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

Quel tipo di codice crufty probabilmente una volta permetteva a questi script di funzionare su un antico sistema Ultrix o altro.

Uno script di configurazione non in esecuzione a causa delle differenze di shell è come arrivare a una gara di Formula 1 con 10 litri di gas e tre ruote di scorta.

Se stai sviluppando uno script di configurazione con Autoconf ed è sensibile al fatto che la shell sia Bash o la shell OSX, stai facendo qualcosa di sbagliato o le persone di Autoconf hanno rotto qualcosa. Se viene da te, correggi qualsiasi shell che stai aggiungendo allo script rendendoli portatili.

Dove viene impostato SHELL? Cosa viene eseguito con / bin / sh quando si desidera / bin / bash?

gli script di configurazione devono essere eseguiti ovunque, anche sulle shell orribilmente rotte e non Bash che esistono in natura.

Modifica : qual è esattamente il problema?

Un'altra modifica : forse ti piacerebbe che lo script si eseguisse nuovamente, qualcosa del genere. Probabilmente è difettoso:

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

ln -f / bin / bash / bin / sh

:-P (No, non è una risposta seria. Per favore, non fare il tubo del sistema facendolo!)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top