it-swarm.it

Perché usiamo "./" (punto slash) per eseguire un file in Linux / UNIX?

Perché usiamo ./filename per eseguire un file in linux?

Perché non inserirlo semplicemente come altri comandi gcc, ls etc ...

89
Renjith G

In Linux, UNIX e relativi sistemi operativi, . indica la directory corrente. Poiché desideri eseguire un file nella directory corrente e tale directory non si trova nel tuo $PATH, hai bisogno del ./ bit per dire a Shell dove si trova l'eseguibile. Così, ./foo significa eseguire il file eseguibile chiamato foo che si trova in questa directory.

Puoi usare type oppure which per ottenere il percorso completo di tutti i comandi trovati nel tuo $PATH.

80
badp

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

Ma perché? In breve, è per la sicurezza. Se stai cercando nella directory home di qualcun altro (o/tmp) e digiti solo gcc o ls, vuoi sapere che stai eseguendo quella vera, non una versione dannosa amico del burlone ha scritto che cancella tutti i tuoi file. Un altro esempio potrebbe essere test o [, che potrebbe sovrascrivere quei comandi negli script Shell, se Shell non li ha come built-in.

Avere . poiché last nel tuo percorso è un po 'più sicuro, ma ci sono altri attacchi che ne fanno uso. Una semplice è 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é i sysadmins hanno probabilità superiori alla media per digitarlo.

103
mattdm

Se vuoi dire, perché hai bisogno ./ All'inizio - questo perché (diversamente da Windows), la directory corrente non fa parte del tuo percorso per impostazione predefinita. Se corri:

$ ls

shell cerca ls nelle directory nella variabile di ambiente PATH (echo $PATH per vederlo) ed esegue il primo eseguibile chiamato ls che trova. Se digiti:

$ a.out

shell funzionerà allo stesso modo, ma probabilmente non troverà un eseguibile chiamato a.out. Devi dire a Shell dove si trova a.out: è nella directory corrente (.) Quindi il percorso è ./a.out.

Se stai chiedendo perché si chiama "a.out", questo è solo il nome del file di output predefinito per gcc. Puoi cambiarlo con la riga di comando -o arg. Per esempio:

$ gcc test.c -o test
$ ./test
45
Simon Whitaker

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

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

TUTTAVIA, ti consiglio vivamente di NON farlo. È cattivo, cattivo, cattivo.

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

. è la directory corrente

.something sarebbe un file nascosto (digita "ALT +" per farli apparire in Nautilus, oppure prova "ls -la".

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

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

4
tiktak

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

Prima di entrare nella logica, dovresti prima conoscere questo fatto: eseguire uno dei:

bin/someprog

o:

/bin/someprog

o:

cd bin
./myexec

esegui bin/someprog senza cercare la variabile PATH per lo stesso identico motivo: tutti bin/someprog, /bin/someprog e ./someprog hanno una barra / In essi.

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

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

Razionale della regola POSIX PERCORSO /

Supponiamo che in esecuzione:

someprog

cercherebbe:

  • relativamente alla CWD prima
  • rispetto al PERCORSO dopo

Quindi, se volevi eseguire /bin/someprog Dalla tua distribuzione, e hai fatto:

someprog

a volte funzionerebbe, ma altri fallirebbe, perché potresti trovarti in una directory che contiene un altro programma someprog non correlato.

Pertanto, impareresti presto che questo non è affidabile e finiresti per usare sempre percorsi assoluti quando vuoi usare PATH, sconfiggendo quindi lo scopo di PATH.

Questo è anche il motivo per cui avere percorsi relativi nel tuo PERCORSO è una pessima idea. Sto ti guardo, node_modules/bin .

Al contrario, supponiamo che in esecuzione:

./someprog

Cerca:

  • prima rispetto al PERCORSO
  • rispetto a CWD dopo

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

/bin/someprog

che è in te PERCORSO da un pacchetto che hai installato dopo aver bevuto troppo dopo Natale l'anno scorso.

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.

Un'altra regola che potresti essere tentato di inventare sarebbe:

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

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

La regola di ricerca del percorso / Offre una soluzione semplice da ricordare al problema about:

  • barra: non usare PATH
  • nessuna barra: usa solo PATH

il che rende super facile sapere sempre cosa stai eseguendo, basandosi sul fatto che i file nella directory corrente possono essere espressi come ./somefile o somefile, e quindi dà un significato speciale a uno di loro.

A volte, è leggermente fastidioso non poter cercare some/prog In relazione a PATH, ma non vedo una soluzione più sicura per questo.