Come dice il titolo, c'è qualche differenza per i filesystem * NIX? eg ls fileels ./file
Risposte:
Non vado matto per la spiegazione di SmallLoanOf1M. È tecnicamente corretto ma risponde in un modo che non corrisponde all'esempio d'uso nella domanda.
Quindi, a titolo di esempio, ecco una differenza importante tra i due dalla domanda: "file" e "./file"
Cosa succede se il file viene nominato con un carattere analizzato dalla shell? Soprattutto per quanto riguarda i personaggi interpretati dal comando uno è in esecuzione.
In particolare, il carattere "trattino": "-". Ma altri personaggi sono significativi per la shell.
Esempio. Il mio file è stato chiamato "-dingle"
Prova a elencare il file:
ls -dingle
# ls -dingle
ls: invalid option -- 'e'
Ancora peggio, e se il file fosse chiamato " -rf rmbomb *"? Ora prova a rimuoverlo
rm "-rf rmbomb *"
Non proverò nemmeno a dare l'esempio, ma spero che tu abbia l'idea.
Quindi, come si fa a elencare un file con il trattino? Utilizzare ./davanti.
# ls ./-dingle
./-dingle
Idem per rm
ls \-dingleo ls \-rf\ rmbomb\ \*. Questo può essere un buon modo per garantire che qualsiasi dato set di comandi sia almeno coerente, poiché specificare ./prima di un nome non sfuggirà ai caratteri dopo il ./.
rm "-rf rmbomb *"farebbe davvero qualcosa di brutto, invece di fare semplicemente rmun errore di stampa. È pericoloso solo se ti dimentichi di citare il nome del file, quindi si verifica la divisione delle parole. (specialmente in uno script di shell in cui esegui rm $fileinvece di rm "$file". Ma in quel caso, *non si espanderà, perché l'espansione glob non si verifica sul contenuto dell'espansione variabile. Se lo desideri, avresti bisogno di un eval.) Comunque, se la tua sceneggiatura divide i nomi dei file prima di passare a rm, creerei un file chiamato space -rf .o qualcosa del genere, quindi rm ./$inon aiuta.
rm: invalid option -- ' ', da quando tenta di interpretare lo spazio -rfcome un interruttore a singolo carattere, perché fa parte dello stesso argomento. (E sì, l'ho eseguito all'interno di una directory vuota nel caso in cui avessi trascurato qualcosa ed era effettivamente pericoloso: P)
IFS=''e -frispettivamente. Un esempio più raro è che awktratta un operando (diverso da un primo operando che è lo script) che ha forma foo=barcome compito da eseguire ma ./foo=barcome file da leggere.
Sì.
Emettendo filedalla riga di comando, BASH cercherà nella propria variabile d'ambiente $ PATH un file con quel nome. A meno che il file non risieda in una directory all'interno della variabile $ PATH, non verrà trovato.
.indica la directory corrente. ./significa all'interno della directory corrente, in termini relativi. È l'equivalente di dire qualcosa come /home/sheogorath/shivering/isles.imgquando si invoca ./isles.imgmentre si lavora nella /home/sheogorath/shivering/directory.
Come tale, viene comunemente utilizzato per eseguire i file all'interno della directory di lavoro "sul posto".
EDIT:
Nel tuo esempio, lsviene chiamato dalla shell e trovato usando la variabile path. Il suo argomento verrà elaborato nella directory di lavoro, qualunque essa sia. Poiché questo è il valore predefinito per ls, non vedrai alcuna differenza tra specificare filee specificare esplicitamente ./filepoiché entrambi puntano alla tua directory corrente.
Non tutti i comandi accetteranno i percorsi dei file nella directory di lavoro e alcuni si aspettano di avere i file in una directory che essi stessi predefiniscono tramite la configurazione. Tra i comandi che accettano file come argomenti, questi comandi sono meno comuni
lsmenzionato nella domanda originale. Questa è più la differenza tra riferire un percorso relativo (rispetto alla directory di lavoro corrente) ../../dir/filename /path/to/dir/filename
lspoiché saranno sempre lo stesso percorso, uno specificato in modo più esplicito rispetto all'altro. Non tutti i comandi si comportano in questo modo durante l'elaborazione degli argomenti, ma molti lo fanno.