Perché utilizziamo “ ./” (punto barra) per eseguire un file in Linux / UNIX?

In Linux, UNIX e sistemi operativi correlati, . denota la directory corrente. Poiché si desidera eseguire un file nella directory corrente e in quella directory non è nel tuo $PATH, hai bisogno del ./ bit per dire alla shell dove leseguibile è. Quindi, ./foo significa eseguire leseguibile chiamato foo che si trova in questa directory.

Puoi usare type o which per ottenere il percorso completo di eventuali comandi trovati nel tuo $PATH.

Commenti

• È molto comune eseguire programmi nella directory corrente. Perché ‘ anche la shell non effettua la ricerca? Prima cerca in., Poi in $ PATH.
• ci sono anche alias es che possono intralciare, non solo $PATH.
• @Michael security and sanity: se cercasse in . prima sarebbe un problema di sicurezza, tu o qualcun altro potreste sostituire ls ad esempio (un semplice virus / trojen: crea un file zip con un eseguibile denominato ls, mentre qualcuno sta cercando, eseguono questo eseguibile, quello …). Se è stato cercato in . per ultimo, puoi passare molto tempo a impazzire senza sapere perché il tuo programma non funziona (es. Crei un programma chiamato test, invece di eseguire il programma viene eseguito il programma di test dei sistemi. Che non produce output).
• @jcubic che ‘ è una pessima idea. Vedi il commento sopra. In passato DOS effettuava ricerche nella directory corrente e quel comportamento veniva portato su Windows cmd, il che introduceva molti problemi di sicurezza. MS ha risolto il problema in PowerShell e ora è necessario utilizzare. \ Per eseguire il programma nella directory corrente
• @ ctrl-alt-delor: Quando ero alluniversità alla fine degli anni 80 ‘ s, questa era una tattica comune (proibita). Scrivendo un programma ” ls ” e lasciandolo nella cartella Inizio nel caso in cui qualcun altro fosse curioso. Il programma si chiamava ” get shell ” IIRC. Proverebbe a ottenere le credenziali dellutente che esegue il comando e quindi potrebbe stampare un falso elenco di directory per lasciarlo alloscuro.

La risposta letterale è come altri hanno dato: perché la directory corrente non è “t nel tuo $PATH.

Ma perché? In breve, è per la sicurezza. Se “stai cercando nella home directory di qualcun altro” (o / tmp) e digiti solo gcc o ls, vuoi so che stai usando quello vero, non una versione dannosa scritta dal tuo amico burlone che cancella tutti i tuoi file. Un altro esempio potrebbe essere test o [, che potrebbe sovrascrivere quei comandi negli script della shell, se la tua shell non li ha incorporati.

Avere . come lultima voce nel tuo percorso è un po più sicura, ma ci sono altri attacchi che ne fanno uso. Un metodo facile è sfruttare errori di battitura comuni, come sl o ls-l. Oppure, trova un comando comune che sembra non essere installato su questo sistema – vim, ad esempio, poiché gli amministratori di sistema hanno una probabilità superiore alla media di digitarlo.

Suona troppo teorico? Lo è in gran parte , ma sicuramente può accadere nella realtà, specialmente su sistemi multiutente. Infatti, ecco un esempio tratto da questo sito in cui un amministratore è passato alla “home directory di un utente e ha trovato ps essere mascherato da un eseguibile con quel nome.

Commenti

• Devi solo avere percorsi assoluti nel PATH variabile dambiente.

Se intendi, perché ne hai bisogno./ allinizio – questo perché (a differenza di Windows), la directory corrente non fa parte del tuo percorso per impostazione predefinita. Se esegui:

$ ls 

la tua shell cerca ls nelle directory della tua variabile dambiente PATH (echo $PATH per vederlo) ed esegue il primo eseguibile chiamato ls che trova. Se digiti:

$ a.out 

la shell farà lo stesso – ma probabilmente non troverà un eseguibile chiamato a.out. Devi dire alla shell dove a.out è: si trova nella directory corrente (.), il percorso è ./a.out.

Se “stai chiedendo perché” viene chiamato “a.out”, questo “è solo il nome del file di output predefinito per gcc. Puoi cambiarlo con largomento della riga di comando -o. Ad esempio:

$ gcc test.c -o test $ ./test 

Commenti

• Grazie.Il mio dubbio è perché hai bisogno di ./ allinizio …. Ho usato “.” (per inserire la directory corrente) ma perché ” / ” dopo?
• / è il separatore di percorso in Linux, quindi lo usi per separare la directory (.) dal nome del file (a.out). Senza di esso hai .a.out che è un valido nome file a sé stante. (Prova touch .a.out; ls -lA per vederlo.)
• è così che specifichi percorso in Unix, <dir>/<file> quindi in pratica stai dicendo di eseguire un file nella directory corrente, che è indicata da ./test
• Red Hat Linux 9? È ora di eseguire laggiornamento!
• Su Windows 10 PowerShell è la shell predefinita ora e richiede anche ./ per eseguire un eseguibile nel percorso corrente

Puoi provare ad aggiungere :. alla tua variabile $ PATH.

Prova ALT + F2 e digita: gksudo gedit /etc/environment se stai usando Linux / GTK (questo è quello che hai se usi Ubuntu).

TUTTAVIA, Ti consiglio vivamente di NON farlo. È brutto cattivo cattivo e cattivo.

Sai, questo genere di cose funziona così dal 1970. Cè una ragione per cui la directory corrente non è inclusa in $ PATH.

. è la directory corrente

.something sarebbe un file nascosto (digita “ALT +” per creare appaiono in Nautilus, oppure prova “ls -la“.

./someProgram.sh è ciò che digiti per eseguire un programma eseguibile .sh nella directory corrente.

.somethingElse significherebbe che hai un eseguibile nascosto nella directory corrente, il che è una cattiva idea.

La regola più completa è in realtà: se qualsiasi barra / è nel percorso, non cercare PATH

Prima di entrare in la logica, dovresti prima conoscere questo fatto: eseguire uno di:

bin/someprog 

o:

oppure:

cd bin ./myexec 

esegui bin/someprog senza cercare PATH variabile per lo stesso identico motivo: tutte le bin/someprog, /bin/someprog e ./someprog hanno una barra /.

someprog da sola non ha una barra /, quindi cerca solo in PATH.

POSIX 7 specifica questa regola in: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

PERCORSO

[…] Se il percorso ricercato contiene un <slash>, la ricerca attraverso i prefissi del percorso non deve essere eseguita .

Razionale per la regola / POSIX PATH

Supponi che in esecuzione:

someprog 

cercherebbe:

• prima relativo a CWD
• relativo a PERCORSO dopo

Quindi, se si desidera eseguire /bin/someprog dalla tua distribuzione e hai fatto:

someprog 

a volte funzionava, ma altre falliva, perché potresti trovarti in una directory che contiene un altro programma someprog non correlato.

Di conseguenza, impareresti presto che questo non è affidabile e finiresti per usare sempre percorsi assoluti quando si desidera utilizzare PATH, quindi vanificando lo scopo di PATH.

Questo è anche il motivo per cui avere percorsi relativi nel proprio PATH è una pessima idea. Io “m ti guardo, node_modules/bin .

Al contrario, supponiamo che in esecuzione:

./someprog 

cerchi:

• relativo a PATH prima
• relativo a CWD dopo

Quindi, se hai appena scaricato uno script someprog da un repository git e desideri eseguirlo da CWD, non saresti mai sicuro che questo sia il programma effettivo che verrebbe eseguito, perché forse la tua distribuzione ha un:

/bin/someprog 

che è in te PATH da qualche pacchetto che hai installato dopo aver bevuto troppo dopo Natale lo scorso anno.

Pertanto, ancora una volta, saresti costretto a eseguire sempre script locali relativi a CWD con percorsi completi per sapere cosa stai eseguendo:

"$(pwd)/someprog" 

che sarebbe anche estremamente fastidioso.

Unaltra regola che potresti essere tentato di elaborare sarebbe:

i percorsi relativi usano solo PATH, i percorsi assoluti solo CWD

ma ancora una volta questo costringe gli utenti a usa sempre abso percorsi di liuto per script non PATH con "$(pwd)/someprog".

La regola di ricerca percorso / offre una soluzione semplice da ricordare al problema relativo:

• barra: non utilizzare PATH
• nessuna barra: utilizzare solo PATH

che rende semplicissimo sapere sempre cosa stai eseguendo, facendo affidamento sul fatto che i file nella directory corrente possono essere espressi come ./somefile o somefile, quindi attribuisce un significato speciale a uno di essi.

A volte è un po fastidioso che tu non possa cercare per some/prog relativo a PATH, ma non vedo una soluzione più sana per questo.