#! / bin / bash – nessun file o directory di questo tipo

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

  • Ho questo problema ora sotto cygwin con uno script che potrei giurare fosse già in esecuzione senza problemi. Ho controllato tutte le risposte, ma nessuno sembra adattarsi. Altre domande e risposte menzionavano anche problemi a 32/64 bit, ma per gli script di shell questo potrebbe essere escluso, giusto?
  • Trovato il motivo, aggiunti dettagli nella nuova anwer unix.stackexchange.com/a/450389/62636 nel caso in cui qualcuno abbia utilizzato anche #!/usr/bin/env bash invece di #!/bin/bash e anche guardando qui …

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 utilizzare dos2unix 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

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 con bash 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.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *