comando non trovato messaggio di errore dopo che provo a eseguire uno script UNIX

Question

Sto imparando come creare script di shell in UNIX, ma continuo a imbattersi in questo stupido errore. Diciamo che faccio uno script come questo:

#!/bin/sh 
echo HELLO 

risparmio il file come prova, e rendere il comando eseguibile da me con chmod 700 test. Risparmio il file nella mia home directory, e (tentativo) per eseguire il file in questo modo:

./test 

Solo per UNIX a rispondere di nuovo:

./test: Command not found. 

Che cosa sta succedendo? Quando digito ls -l, c'è un asterisco accanto al nome del file. Non era lì prima che usassi il comando chmod. Qualcuno può dirmi cosa sto facendo di sbagliato?

Answer 1

Sembra che tu abbia bisogno di una barra prima del bidone:

#!/bin/sh 
#^

Tutto il resto sembra bene ... Sto assumendo che /bin/sh è la posizione della vostra shell Bournse eseguibile - se non lo è , avresti bisogno di aggiustare il caso. Senza la barra principale, la shell sta cercando bin/shrelativo alla directory corrente, anziché dove risiede realmente.

È necessario individuare l'interprete shell eseguibile che si desidera (o necessario) per gli script.

Un altro paio di suggerimenti - sulla mia macchina ho ottenere questi risultati:

# tells you where sh resides, if it is on your path 
$ which sh 
/bin/sh 

# tells you which shell you are currently using 
$ echo $SHELL 
/bin/tcsh 

posso usare uno di questi per il 'shebang' linea in un semplice script di shell. Ad esempio, è possibile che la shell Bourne si trovi in ​​/usr/bin anziché in /bin.

Answer 2

Il #! indica a Unix di eseguire lo script utilizzando il programma specificato. Nel tuo caso hai specificato bin/sh, ma dovrebbe essere /bin/sh. Il messaggio di errore che Unix dà non è particolarmente chiaro su quale programma non possa trovare.

Answer 3

renderlo eseguibile:

chmod +x ./test 

e assicurarsi di salvare il file in formato di file Unix. E: controlla se la tua partizione è eseguibile (mount).

Answer 4

Per aggiungere alla risposta di Martin, si dice di salvare il file nella propria directory home ed eseguirlo come ./test. Funzionerà solo se la tua directory di lavoro corrente è la stessa della tua home directory.

L'asterisco accanto al nome del file indica che il file è eseguibile.

Answer 5

Se ./test è uno script eseguibile eppure l'esecuzione fornisce il messaggio di errore ./test: Command not found, verificare che l'interprete esista. È necessario indicare un percorso assoluto (la variabile di ambiente PATH non viene utilizzata).

Se il file è passato attraverso una macchina Windows, assicurarsi che non ci sia un ritorno a capo spuria alla fine della riga, poiché CR sarebbe parte del nome del file dell'interprete. È possibile verificare con <test head -n 1 | od -t x1: se questo termina con 0d 0a, c'è un CR e è necessario rimuoverlo (potrebbe essere necessario rimuovere CR anche da altre linee).

Answer 6

Questo è davvero molto strano. I passaggi che hai descritto dovrebbero aver funzionato, quindi ci deve essere un piccolo errore nel tuo ambiente o l'esecuzione di tali passaggi. Ci sono alcune cose che puoi fare per aiutare a diagnosticare questo:

CONTROLLO caratteri di controllo

Quello che hai documentato guarda bene, a patto che non ci sono errori di battitura o caratteri di controllo. È necessario verificare digitando:

cat -vt ./test 

Se si vede un testo extra inaspettato che potrebbe spiegare il problema. Ad esempio, "^ M" alla fine di una riga indica che il tuo editor ha salvato il file in formato Windows.

rigenerare il FILE AFFIDABILE

Per creare una nota buona ./test2, copiare e incollare i seguenti comandi:

`which bash` 
printf "#\!`which sh`\necho HELLO\n" > ./test2 
chmod +x ./test2 
./test2 
exit 

CONTROLLO quale comando non può essere trovato

Se si digita .. .

./ajio 

... si fa a ottenere esattamente ...

./ajio: Command not found. 

... come descritto con ./test? Ho appena inventato il nome ajio, quindi non dovrebbe esistere. Se i messaggi corrispondono, in realtà non ti dice nulla di nuovo. Ma se i messaggi differiscono, ciò conferma che lo ./test è stato trovato ed eseguibile almeno.

E 'anche possibile che la versione di sh sta cercando di dirti di non che test non può essere trovato, ma che durante l'esecuzione di un comando test il guscio cercato di correre non è stato trovato. Questo non dovrebbe essere il comando echo, come con la maggior parte delle implementazioni della shell che sarà un comando interno, implementato all'interno della shell. Ma, la shell può eseguire uno script di inizializzazione contenente una riga che specifica un comando che non può essere eseguito. Se esegui man sh, ti verranno comunicati tutti i diversi file di avvio che la tua shell potrebbe provare a eseguire. Questi possono essere diversi da quelli usati quando si avvia la shell in modo interattivo. Ma, come principiante, può essere scoraggiante verificare la validità di tali script. È probabile che qualsiasi personalizzazione fasulla sia comunque per il processo di avvio della shell personale e non affligga l'intera installazione di Linux, quindi esegui ls -ld ~/.* per elencare i file nascosti nella tua home directory e ispeziona qualsiasi aspetto simile ai file di avvio della shell (ad esempio ~/.bashrc, ~/.profile, ~/.bash_login). Verifica che tutti i comandi specificati possano essere trovati con i quali e vengono richiamati dopo che la variabile percorso è stata impostata per includere la loro posizione.

CONFRONTO AD UN ALTRO SHELL

Se c'è un problema con il/bin/sh install/inizializzazione, allora si potrebbe essere in grado di bypassare lo invocando un'altra shell. Provare...

which zsh 
which tcsh 
which csh 

... e se uno di più di questi reperti un guscio alternativo per voi, modificare o ricreare il file che specifica che la Shell, ala ...

#!/bin/csh 
echo HELLO 

... poi si chmod +x e ./ -runalo. Se funziona, allora sai che il tuo problema è/bin/sh specifico.

Answer 7

Ho avuto lo stesso problema in cui ho copiato il file da Windows a Linux e ho provato ad eseguirlo. Ho fatto tutti i suggerimenti sopra, ma nulla è stato di aiuto fino a quando non ho fatto un dos2unix sul file e l'ho risolto. Potrebbe non essere il tuo caso, ma è sufficiente metterlo lì fuori

Answer 8

Ho avuto un problema simile con una vecchia macchina virtuale SCO OpenServer 5.0.7. mi ha spinto noci che non ho potuto eseguire alcuni script che è iniziato con

"#!/bin/bash"

(meno le virgolette, ovviamente) Durante la lettura i fili qui, mi sono reso conto per verificare se/bin/bash esisteva addirittura. Risulta che mancava. Ho installato da un CD SKUNKWARE2000 e tutto andava bene.

Answer 9

Innanzitutto, controllare se è presente/bin/sh, in caso contrario, questo è il tuo problema.

Se è installato/bin/sh, penso che ciò accada se il percorso non è configurato correttamente. In questo caso è possibile provare: /bin/sh test.sh dalla directory di lavoro corrente in cui si trova test.sh.

Prova anche dos2unix test.sh se hai copiato il file da windows.

Answer 10

provare chmod u+x ./test

So che da qui: http://www.linuxquestions.org/questions/red-hat-31/running-shell-script-command-not-found-202062/