Per avviare lo script di shell 'file.sh':
sh file.sh
bash file.sh
Un'altra opzione è impostare il permesso eseguibile usando il comando chmod:
chmod +x file.sh
Ora esegui il file .sh come segue:
./file.sh
Per eseguire un sh non eseguibile script, usa:
sh myscript
Per eseguire un bash non eseguibile script, usa:
bash myscript
Per avviare un eseguibile (che è qualsiasi file con autorizzazione eseguibile); basta specificarlo tramite il suo percorso:
/foo/bar
/bin/bar
./bar
Per rendere eseguibile uno script, assegnagli i permessi necessari:
chmod +x bar
./bar
Quando un file è eseguibile, il kernel è responsabile di capire come eseguirlo. Per i non binari, questo viene fatto guardando la prima riga del file. Dovrebbe contenere un hashbang :
#! /usr/bin/env bash
L'hashbang dice al kernel quale programma eseguire (in questo caso il comando /usr/bin/env viene eseguito con l'argomento bash ). Quindi, lo script viene passato al programma (come secondo argomento) insieme a tutti gli argomenti che hai fornito allo script come argomenti successivi.
Ciò significa che ogni script eseguibile dovrebbe avere un hashbang . In caso contrario, non stai dicendo al kernel cos'è è , e quindi il kernel non sa quale programma usare per interpretarlo. Potrebbe essere bash , perl , python , sh , o qualcos'altro. (In realtà, il kernel userà spesso la shell predefinita dell'utente per interpretare il file, il che è molto pericoloso perché potrebbe non essere affatto l'interprete giusto o potrebbe essere in grado di analizzarne una parte ma con sottili differenze comportamentali come è il caso tra sh e bash ).
Una nota su /usr/bin/env
Più comunemente, vedrai hash bang in questo modo:
#!/bin/bash
Il risultato è che il kernel eseguirà il programma /bin/bash interpretare la sceneggiatura. Sfortunatamente, bash non è sempre fornito per impostazione predefinita e non è sempre disponibile in /bin . Mentre su macchine Linux di solito lo è, ci sono una serie di altre macchine POSIX in cui bash spedisce in varie località, come /usr/xpg/bin/bash o /usr/local/bin/bash .
Per scrivere uno script bash portatile, non possiamo quindi fare affidamento sull'hard-coding della posizione di bash programma. POSIX ha già un meccanismo per gestirlo:PATH . L'idea è di installare i programmi in una delle directory che si trovano in PATH e il sistema dovrebbe essere in grado di trovare il tuo programma quando vuoi eseguirlo per nome.
Purtroppo, non puoi basta fare questo:
#!bash
Il kernel non eseguirà (alcuni potrebbero) un PATH cercarti. C'è un programma che può fare un PATH cerca te, però, si chiama env . Fortunatamente, quasi tutti i sistemi hanno un env programma installato in /usr/bin . Quindi iniziamo env utilizzando un percorso hardcoded, che quindi esegue un PATH cerca bash e lo esegue in modo che possa interpretare il tuo script:
#!/usr/bin/env bash
Questo approccio ha uno svantaggio:secondo POSIX, l'hashbang può avere un argomento . In questo caso, usiamo bash come argomento del env programma. Ciò significa che non abbiamo più spazio per passare argomenti a bash . Quindi non c'è modo di convertire qualcosa come #!/bin/bash -exu a questo schema. Dovrai inserire set -exu dopo l'hashbang invece.
Questo approccio ha anche un altro vantaggio:alcuni sistemi possono essere forniti con un /bin/bash , ma all'utente potrebbe non piacere, potrebbe trovarlo difettoso o obsoleto e potrebbe aver installato il proprio bash altrove. Questo è spesso il caso su OS X (Mac) in cui Apple fornisce un /bin/bash obsoleto e gli utenti installano un /usr/local/bin/bash aggiornato usando qualcosa come Homebrew. Quando usi il env approccio che fa un PATH search, prendi in considerazione le preferenze dell'utente e usi la sua bash preferita rispetto a quella fornita con il suo sistema.
Per la bourne shell:
sh myscript.sh
Per bash:
bash myscript.sh