Perché è necessario ./ (dot-slash) prima dell’eseguibile o del nome dello script per eseguirlo in bash?

Quando eseguo gli script in bash, devo scrivere ./ all’inizio:

 $ ./manage.py syncdb 

Se non lo faccio, ricevo un messaggio di errore:

 $ manage.py syncdb -bash: manage.py: command not found 

Qual è la ragione di questo? Ho pensato è un alias per la cartella corrente e pertanto queste due chiamate dovrebbero essere equivalenti.

Inoltre, non capisco perché non ho bisogno ./ durante l’esecuzione di applicazioni, come ad esempio:

 user:/home/user$ cd /usr/bin user:/usr/bin$ git 

(che funziona senza ./ )

Perché su Unix, di solito, la directory corrente non è in $PATH .

Quando si digita un comando, la shell cerca un elenco di directory, come specificato dalla variabile PATH . La directory corrente non è in quella lista.

La ragione per non avere la directory corrente su quell’elenco è la sicurezza.

Diciamo che sei root e vai nella directory di un altro utente e digita sl invece di ls . Se la directory corrente è in PATH , la shell proverà a eseguire il programma sl in quella directory (poiché non vi sono altri programmi sl ). Quel programma sl potrebbe essere malizioso.

Funziona con ./ perché POSIX specifica che un nome di comando che contiene un / sarà usato direttamente come nome file, sopprimendo una ricerca in $PATH . Potresti aver usato il percorso completo per lo stesso identico effetto, ma ./ è più breve e più facile da scrivere.

MODIFICARE

Quella parte sl era solo un esempio. Le directory in PATH sono ricercate in sequenza e quando viene eseguita una corrispondenza viene eseguito quel programma. Quindi, a seconda di come appare PATH , digitare un comando normale può essere o non essere sufficiente per eseguire il programma nella directory corrente.

Quando bash interpreta la riga di comando, cerca i comandi nelle posizioni descritte nella variabile di ambiente $PATH . Per vederlo scrivi:

 echo $PATH 

Avrai alcuni percorsi separati da due punti. Come vedrai il percorso corrente . di solito non è in $PATH . Quindi Bash non riesce a trovare il tuo comando se si trova nella directory corrente. Puoi cambiarlo avendo:

 PATH=$PATH:. 

Questa riga aggiunge la directory corrente in $PATH modo che tu possa fare:

 manage.py syncdb 

Non è raccomandato in quanto ha problemi di sicurezza, in più puoi avere comportamenti strani, come . varia sulla directory in cui ti trovi 🙂

Evitare:

 PATH=.:$PATH 

Come si può “mascherare” alcuni comandi standard e aprire la porta alla violazione della sicurezza 🙂

Solo i miei due centesimi.

Il tuo script, quando nella tua home directory non verrà trovato quando la shell guarda la variabile d’ambiente $PATH per trovare il tuo script.

Il file ./ dice “guarda nella directory corrente per il mio script invece di guardare tutte le directory specificate in $PATH “.

Quando includi il “.” stai essenzialmente dando il “percorso completo” allo script bash eseguibile, quindi la tua shell non ha bisogno di controllare la tua variabile PATH. Senza il ‘.’ la tua shell apparirà nella tua variabile PATH (che puoi vedere eseguendo echo $PATH per vedere se il comando che hai scritto risiede in una delle cartelle sul tuo PATH. Se non lo è (come nel caso di manage.py) dice che non riesce a trovare il file. È considerata una ctriggers pratica includere la directory corrente sul PATH, che è spiegata abbastanza bene qui: http://www.faqs.org/faqs/unix-faq/faq/part2 /section-13.html

Su * nix, a differenza di Windows, la directory corrente di solito non è nella variabile $PATH . Quindi la directory corrente non viene ricercata quando si eseguono i comandi. Non è necessario ./ per le applicazioni in esecuzione perché queste applicazioni si trovano nel tuo $ PATH; molto probabilmente sono in /bin o /usr/bin .

Questa domanda ha già alcune risposte fantastiche, ma volevo aggiungere che, se il tuo eseguibile si trova sul PERCORSO, e ottieni risultati molto diversi quando corri

 ./executable 

a quelli che ottieni se corri

 executable 

(diciamo che si incontrano messaggi di errore con l’uno e non l’altro), il problema potrebbe essere che si hanno due diverse versioni dell’eseguibile sulla propria macchina: una sul percorso e l’altra no.

Controlla questo funzionando

quale eseguibile

e

 whereis executable 

Risolve i miei problemi … Avevo tre versioni dell’eseguibile, solo una delle quali era compilata correttamente per l’ambiente.

Quando lo script non si trova nel percorso è necessario farlo. Per maggiori informazioni leggi http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html

C’è differenza tra la Current Directory e la Current Directory Working Directory che potresti trovare su google facilmente. Questo è il motivo per cui manage.py syncdb non esegue come previsto.

Directory corrente : è la directory da cui viene eseguita la shell o il processo padre.

 you are right "." is for current directory. 

Nel sistema basato su UNIX se hai il tuo file in /data/myfile.out allora stai attraversando il tuo file attraverso i nomi dei componenti che sono separati dalla forward slash "/" quindi se "." è la tua directory corrente quindi se vuoi accedere (esegui nel tuo caso) file che si trova all’interno della tua directory corrente dovrai dire ./myexecutableFile.o . Se avessi il tuo file eseguibile in un’altra cartella della tua directory corrente, dovresti fare qualcosa del genere ./myFiles/myexecutableFile.o . Spero che tu abbia quello che sto cercando di spiegare.