Ho “creato uno script bash ma quando provo a eseguirlo, ottengo
#!/bin/bash no such file or directory
Devo eseguire il comando: bash script.sh
affinché funzioni.
Come posso risolvere questo problema?
Commenti
Risposta
Questo tipo di messaggio è solitamente dovuto a una falsa linea di shebang, o un ritorno in carrozza extra alla fine dellabete prima riga o una distinta materiali allinizio di essa.
Esegui:
$ head -1 yourscript | od -c
e guarda come finisce.
Questo è sbagliato:
0000000 # ! / b i n / b a s h \r \n
Anche questo è sbagliato:
0000000 357 273 277 # ! / b i n / b a s h \n
È corretto:
0000000 # ! / b i n / b a s h \n
Usa dos2unix
(o sed
, tr
, awk
, perl
, python
…) per correggere lo script se questo è il problema.
Eccone uno che rimuoverà sia una distinta componenti che le risposte predefinite:
sed -i "1s/^.*#//;s/\r$//" brokenScript
Nota che la shell che stai utilizzando per eseguire lo script influenzerà leggermente i messaggi di errore che vengono visualizzati.
Qui ci sono tre script che mostrano solo il loro nome (echo $0
) e con le seguenti rispettive righe shebang:
correctScript:
0000000 # ! / b i n / b a s h \n
scriptWithBom:
0000000 357 273 277 # ! / b i n / b a s h \n
scriptWithCRLF:
0000000 # ! / b i n / b a s h \r \n
In bash, eseguendoli verranno visualizzati questi messaggi:
$ ./correctScript ./correctScript $ ./scriptWithCRLF bash: ./scriptWithCRLF: /bin/bash^M: bad interpreter: No such file or directory $ ./scriptWithBom ./scriptWithBom: line 1: #!/bin/bash: No such file or directory ./scriptWithBom
Esecuzione di bo quelli gus chiamando esplicitamente linterprete consentono allo script CRLF di essere eseguito senza problemi:
$ bash ./scriptWithCRLF ./scriptWithCRLF $ bash ./scriptWithBom ./scriptWithBom: line 1: #!/bin/bash: No such file or directory ./scriptWithBom
Ecco il comportamento osservato in ksh
:
$ ./scriptWithCRLF ksh: ./scriptWithCRLF: not found [No such file or directory] $ ./scriptWithBom ./scriptWithBom[1]: #!/bin/bash: not found [No such file or directory] ./scriptWithBom
e sotto dash
:
$ ./scriptWithCRLF dash: 2: ./scriptWithCRLF: not found $ ./scriptWithBom ./scriptWithBom: 1: ./scriptWithBom: #!/bin/bash: not found ./scriptWithBom
Commenti
- Un altro modo per rivelare se questo è il problema è
hexdump -C yourscript | head -n 1
. Vorrei comunque utilizzaredos2unix yourscript
per risolverlo. - Se fosse un problema CRLF, ‘ non vedresti un
#!/bin/bash no such file or directory
messaggio di errore, poiché ‘ non cè motivo per cui qualcosa potrebbe tentare di eseguire o aprire#!/bin/bash
. ‘ è/bin/bash<CR>
ciò che verrebbe eseguito. - @StephaneChazelas Poiché dos2unix ha risolto il problema, non ci sono dubbi ‘ non era un problema CRLF. Il messaggio di errore è stato probabilmente trascritto in modo impreciso.
-
dos2unix
rimuove anche una distinta componenti UTF-8. Un BOM UTF-8 potrebbe aver spiegato il messaggio di errore. - È triste quanto Microsoft sia incompatibile. Anche con qualcosa di semplice come ASCII.
Risposta
Questo può anche essere causato da una distinta materiali in un UTF -8 script. Se crei lo script in Windows, a volte ottieni della spazzatura allinizio del file.
Commenti
- BOM può essere rimosso facilmente utilizzando awk, come in stackoverflow.com/questions/1068650/…
- Tieni presente che Visual Studio per Il Mac inserirà una distinta materiali.
Risposta
In realtà, lo shebang corretto per lo script bash è questo:
#!/usr/bin/env bash
Perché, in freeBSD, bash si trova in /usr/local/bin/bash
Commenti
- ” right ” è una parola difficile da usare in questi casi. Forse una frase migliore sarebbe ” meno soggetta a errori “.
- Anche questo è terribile; il presupposto che / usr esista è pessimo IMO. Haiku, ad esempio, non ha / usr.
Risposta
Puoi usare vi per risolvere entrambi i problemi se esistono:
vi <your_file> :set ff=unix :set nobomb :wq
Commenti
- Le risposte dovrebbero essere il più possibile autonome. La domanda non menziona due problemi; se hai intenzione di basarti su altre risposte, dovresti almeno dire cosa sono. Meglio ancora, dovresti spiegare come questo risponde alla domanda.
- Soluzione molto rapida senza scaricare altri strumenti di Windows, grazie!
- @ G-Man Altre risposte lo menziono già in modo molto più dettagliato di quanto vorrei approfondire.Non cè bisogno di ripetere, ma se ‘ non è dolorosamente ovvio, puoi avere una fine di riga di Windows e un carattere BOM di Windows nascosto. Penso che molte persone che scansionano le risposte apprezzino la brevità invece di essere autosufficienti, specialmente quando ci sono molti più dettagli in altre risposte.
Risposta
Se non hai dos2unix questo è un modo per risolvere questo problema.
cp script _p4 && tr -d "\r" < _p4 > script && rm _p4
Risposta
Byte-order Mark (BOM)
Ciò potrebbe essere causato da una BOM. Da Wikipedia, una BOM è un
Il byte order mark (BOM) è un carattere Unicode, U + FEFF byte order mark (BOM) , il cui aspetto come un numero magico allinizio di un flusso di testo può segnalare diverse cose a un programma che consuma il testo
Sfortunatamente, non segnala nulla al kernel Linux che gestisce la riga she-bang. Puoi verificare di avere una BOM utilizzando file
,
file /tmp/foo /tmp/foo: UTF-8 Unicode (with BOM) text
Oppure puoi eseguire il dump esadecimale i primi caratteri e vedi se corrispondono manualmente a uno dei caratteri BOM
Puoi rimuovere i caratteri BOM una volta che li conosci in questo modo ,
sed -i "1 s/^\xef\xbb\xbf//" *.txt
Risposta
Ho avuto il problema aggiungendo accidentalmente una bash sbagliata eseguibile nel PATH
e perché nel mio script è stato utilizzato il più flessibile #!/usr/bin/env bash
shebang (prendi il primo eseguibile bash dal percorso).
command -v bash /cygdrive/c/Program Files/Git/bin//bash
Ho installato GIT per Windows per funzionare in cygwin
insieme alle GUI GIT di Windows (non funzionava con cygwin native git …). Ho risolto il problema passando a #!/bin/bash
sheband e rimuovendo GIT per Windows da PATH
.
Risposta
Prova #!/bin/bash
Seconda cosa: find / -name bash
Terza cosa: ls -al /bin/bash
Commenti
- O semplicemente
which bash
. Sappiamo che ‘ ne sta trovando uno perché ‘ sta lavorando conbash script.sh
. - Vero. E come accennato, esiste il metodo / usr / bin / env molto più portabile per far sì che un programma individui bash (o un altro interprete) per te. Non cè bisogno di codificare un pah.
#!/usr/bin/env bash
invece di#!/bin/bash
e anche guardando qui …