Il comando "bash" esegue script nella versione 3.2, non 4.4

2

Attualmente, nel terminale, la mia shell interattiva predefinita è la versione 4.4 di bash. Il sistema operativo viene fornito con 3.2.

Se voglio eseguire uno script (ad esempio my_script.sh ) utilizzando la versione 4.4 di bash, posso trovarlo ( source my_script.sh ) o scriverlo direttamente nel mio terminale. Tuttavia, in ogni caso lo script viene eseguito nella mia shell corrente. Posso anche dare uno script per eseguire le autorizzazioni ed eseguirlo come un comando, permettendo allo shebang di controllare quale versione di bash usare.

Tuttavia, il comando bash continua a utilizzare la versione 3.2. Ad esempio, se eseguo bash my_script.sh , lo script verrà eseguito in una nuova shell (che desidero), ma verrà utilizzata la versione precedente di bash (3.2). Allo stesso modo, se eseguo solo bash senza argomenti, una nuova shell si apre usando la versione 3.2 (richiama, se apro una nuova finestra o una scheda nel terminale, usa la mia shell predefinita, bash v. 4.4. cosa succede quando uso il comando bash ).

Ho aggiunto il percorso a bash 4.4 sulla mia macchina ( /usr/local/bin/bash ) alla mia PATH variabile in .bash_profile , e non viene sovrascritto da qualche altra parte ( echo $PATH fornisce il risultato atteso: il primissimo il percorso è usr/local/bin/bash ). Mi aspettavo che questo modificasse il comportamento del comando bash

Posso usare una soluzione alternativa, impostando un alias ( alias bash4='/usr/local/bin/bash' ), ma non devo usare un alias per bash 3.2, o per versioni aggiornate di, ad esempio, python o R.

C'è qualcosa che mi manca? La soluzione alias è l'unica opzione qui?

EDITS

in risposta ai commenti:

SHELL è /usr/local/bin/bash , che non è sorprendente, poiché è la mia shell di login predefinita.

type -a bash è interessante ...

bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash

Il mio intero PATH è un casino, che potrebbe essere la fonte di questo problema.

/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin

problema non correlato con il mio percorso, ho inavvertitamente ripetuto $PATH in una riga del mio .bash_profile , (PATH = $ PATH :: $ PATH) causando la duplicazione indesiderata

    
posta De Novo 16.11.2018 - 21:00
fonte

3 risposte

3

L'errore qui è che il primo percorso in PATH era nell'eseguibile bash, invece che nella directory che contiene l'eseguibile di bash. Per i lettori con problemi simili: verifica che ogni percorso che stai aggiungendo alla tua variabile PATH si risolva in una directory, non in un file.

Problema:

Ho aggiunto quanto segue al mio .bash_profile :

PATH=/usr/local/bin/bash:$PATH

/usr/local/bin/bash non è una directory. È un file (beh, un link simbolico a un file). Quindi, indipendentemente dal fatto di posizionarlo all'inizio di PATH , il comando bash non troverà un file eseguibile denominato bash all'interno di qualsiasi directory in PATH finché non arriva a /bin .

Soluzione:

In .bash_profile , impostazione

PATH=/usr/local/bin:$PATH

Risolve il problema. Ora il comando bash trova l'eseguibile dentro /usr/local/bin prima che arrivi a /bin .

    
risposta data 16.11.2018 - 21:50
fonte
1

Se si desidera utilizzare bash 4.4 come shell predefinita, effettuare le seguenti operazioni:

  1. rinomina il file /bin/bash con qualcos'altro ( bash3 per esempio)

    sudo mv /bin/bash /bin/bash3
    
  2. crea un link simbolico dal tuo /usr/local/bin/bash a /bin/bash

    sudo ln -s /usr/local/bin/bash /bin/bash
    

Ora, ogni volta che apri una shell, si aprirà la versione 4.x di bash e se hai mai bisogno di eseguire bash v3.x, semplicemente invoca bash3 .

    
risposta data 16.11.2018 - 21:33
fonte
0

Perché non istruisci esplicitamente lo script per fare la tua offerta esatta?

Non avviarlo con

#!/bin/sh 

o qualunque sia il tuo shebang.

Ma prova come la prima riga del tuo script bash

#!/usr/local/bin/bash 

Se i problemi derivano dal tentativo di eseguire

When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.

Quindi è possibile forzare la tua volontà senza un ambiente PATH ripulito (anche se è ancora consigliabile ripulirlo) usando i percorsi assoluti:

Quando si esegue uno script bash con il comando /usr/local/bin/bash my_script.sh

Ma per quei casi un alias per il percorso completo bash potrebbe tornare utile ...

    
risposta data 16.11.2018 - 22:39
fonte

Leggi altre domande sui tag