Risposte:
locate(1)ha solo un grande vantaggio rispetto alla find(1)velocità.
find(1), tuttavia, presenta molti vantaggi rispetto a locate(1):
find(1)è primordiale, risalendo alla primissima versione di AT&T Unix . Lo troverai anche in Linux embedded ridotti tramite Busybox . È tutt'altro che universale.
locate(1)è molto più giovane di find(1). Il primo antenato di locate(1) non è apparso fino al 1983 , e non è stato ampiamente disponibile come " locate" fino al 1994, quando è stato adottato in GNU findutils e in 4.4BSD .
locate(1)è anche non standard , quindi non è installato di default ovunque. Alcuni sistemi operativi di tipo POSIX non lo offrono nemmeno come opzione e, laddove disponibile, l'implementazione potrebbe non disporre delle funzionalità desiderate poiché non esiste uno standard indipendente che specifica il set minimo di funzionalità che deve essere disponibile.
C'è un fatto normale, essendo BSDlocate(1) , ma che è solo perché gli altri due sapori principali di locateimplementare tutte le sue opzioni: -0, -c, -d, -i, -l, -m, -s, e -S. mlocateimplementa 6 opzioni aggiuntive non in BSD locate: -b, -e, -P, -q, --regexe -w. GNUlocate implementa quei sei più un altro a quattro : -A, -D, -E, e -p. (Sto ignorando gli alias e le differenze minori come -?vs -hvs. --help)
I BSD e Mac OS X forniscono BSD locate.
La maggior parte dei Linux spedisce GNU locate, ma Red Hat Linux e Arch mlocateinvece lo fanno. Debian non installa né nella sua installazione di base, ma offre entrambe le versioni nei suoi repository di pacchetti predefiniti; se entrambi sono installati contemporaneamente, " locate" viene eseguito mlocate.
Oracle è stato spedito mlocatein Solaris dall'11.2 , rilasciato a dicembre 2014. In precedenza, locatenon era installato di default su Solaris. (Presumibilmente, ciò è stato fatto per ridurre l'incompatibilità dei comandi di Solaris con Oracle Linux , che si basa su Red Hat Enterprise Linux , che utilizza anche mlocate.)
IBM AIX non fornisce ancora alcuna versione di locate, almeno a partire da AIX 7.2 , a meno che non si installi GNU findutilsda AIX Toolbox per applicazioni Linux .
HP-UX inoltre sembra mancare locatenel sistema di base.
Gli Unix "reali" meno recenti in genere non includevano un'implementazione di locate.
find(1)ha una potente sintassi di espressione, con molte funzioni, operatori booleani , ecc.
find(1)può selezionare i file con più di un semplice nome. Può selezionare per:
Quando si trovano i file per nome, è possibile eseguire la ricerca utilizzando la sintassi globbing dei file in tutte le versioni di find(1)GNU o BSD, oppure usando le espressioni regolari .
Le versioni attuali di locate(1)accettano i modelli glob come findfa, ma BSD locatenon fa affatto regex. Se sei come me e devi usare una varietà di tipi di macchine, ti ritrovi a preferire il grepfiltro a sviluppare una dipendenza da -ro --regex.
locateha bisogno di un filtro forte più di quanto findnon faccia perché ...
find(1)non cerca necessariamente l'intero file system. In genere lo si punta su una sottodirectory, un genitore contenente tutti i file su cui si desidera operare. Il comportamento tipico di locate(1)un'implementazione è quello di vomitare tutti i file corrispondenti al modello, lasciandoli al grepfiltro e in modo tale da ridurne le dimensioni.
(Suggerimento male: locate /probabilmente otterrai un elenco di tutti i file sul sistema!)
Ci sono varianti di locate(1)like slocate(1)che limitano l'output in base alle autorizzazioni dell'utente, ma questa non è la versione predefinita di locatenessun sistema operativo principale.
find(1)può fare cose sui file che trova, oltre a trovarli. L'operatore più potente e ampiamente supportato è -exec, ma ce ne sono altri. In recenti GNU e BSD trovano implementazioni, ad esempio, hai gli operatori -deletee -execdir.
find(1) viene eseguito in tempo reale, quindi il suo output è sempre aggiornato.
Poiché locate(1)si basa su un database aggiornato ore o giorni in passato, il suo output può essere obsoleto. (Questo è il problema della cache non aggiornato .) Questa moneta ha due facce:
locate può nominare i file che non esistono più.
GNU locatee mlocatehanno il -eflag per farlo verificare l'esistenza del file prima di stampare il nome di ogni file scoperto in passato, ma questo elimina alcuni dei locatevantaggi di velocità e non è disponibile in BSD locate.
locate non riuscirà a nominare i file creati dall'ultimo aggiornamento del database.
Impari a diffidare un po ' locatedell'output, sapendo che potrebbe essere sbagliato.
Esistono modi per risolvere questo problema, ma non sono a conoscenza di implementazioni di uso diffuso. Ad esempio, c'è rlocate, ma sembra non funzionare con nessun kernel Linux moderno.
find(1) non ha mai più privilegi rispetto all'utente che lo esegue.
Poiché locatefornisce un servizio globale a tutti gli utenti su un sistema, vuole che il suo updatedbprocesso sia eseguito in rootmodo da poter vedere l'intero filesystem. Ciò porta a una scelta di problemi di sicurezza:
Esegui updatedbcome root, ma rendi leggibile il suo file di output in modo che locatepossa essere eseguito senza privilegi speciali. Questo espone efficacemente i nomi di tutti i file nel sistema a tutti gli utenti. Potrebbe trattarsi di una violazione della sicurezza per causare un problema reale.
BSD locateè configurato in questo modo su Mac OS X e FreeBSD.
Scrivi il database come leggibile solo da roote crea il locate setuidroot in modo che possa leggere il database. Ciò significa che locatedeve reimplementare efficacemente il sistema di autorizzazione del sistema operativo in modo che non mostri file che normalmente non si possono vedere. Aumenta anche la superficie di attacco del tuo sistema, rischiando in particolare un attacco di escalation di root .
Creare un " locate" utente o gruppo speciale per possedere il file di database e contrassegnare il file locatebinario come setuid/setgidper quell'utente / gruppo in modo che possa leggere il database. Questo non impedisce attacchi di escalation di privilegi da soli, ma mitiga notevolmente il danno che si potrebbe causare.
mlocateè configurato in questo modo su Red Hat Enterprise Linux .
Tuttavia, hai ancora un problema, perché se è possibile utilizzare un debugger locateo farlo scaricare core, è possibile accedere a parti privilegiate del database.
Non vedo un modo per creare un locatecomando veramente "sicuro" , a meno di eseguirlo separatamente per ogni utente sul sistema, il che ne nega gran parte del vantaggio find(1).
In conclusione, entrambi sono molto utili. locate(1)è meglio quando stai solo cercando di trovare un determinato file per nome, che sai esiste, ma semplicemente non ricordi dove si trova esattamente. find(1)è meglio quando hai un'area focalizzata da esaminare o quando hai bisogno di uno dei suoi numerosi vantaggi.
find -- "$dir" non robusta ( $dirpuò essere presa per un predicato), nessun modo per testare gli attributi di un link simbolico, problemi di condizioni della razza ... Per me finde locateaffrontare due diversi problemi. Ci sono molti posti in cui l'uso di find non è realistico (come le directory che contengono milioni di file). individuare è un sistema di indicizzazione limitato ai nomi dei file.
locatefurono all'incirca simili find / -type f | gzip > locate.gz, ezgrep "$1" <locate.gz
locateè nel findutilspacchetto e il suo updatedbprogramma è implementato in termini di find(1). Quindi, in tal senso, in locate(1)realtà richiede find(1) . :)
find, locatee così via in altre sezioni in modo che non ha bisogno di essere lì per disambiguare lo stesso nome usato in diverse sezioni il manuale (es. unlink(1)vs unlink(2)), quelli di noi abituati alla convenzione lo vedono come riferimento a una pagina man.
locateutilizza un database predefinito, che dovrebbe essere aggiornato regolarmente, mentre findscorre su un filesystem per individuare i file.
Pertanto, locateè molto più veloce di find, ma può essere inaccurato se il database -può essere visto come una cache- non viene aggiornato (vedi updatedbcomando).
Inoltre, findpuò offrire una maggiore granularità, in quanto puoi filtrare i file per ogni attributo di esso, mentre locateusa un modello abbinato ai nomi dei file.
findnon è possibile per un principiante o un utente occasionale di Unix utilizzare con successo senza un'attenta lettura della pagina man. Storicamente, alcune versioni di findnon hanno nemmeno predefinito l' -printopzione, aggiungendo all'ostilità dell'utente.
locate è meno flessibile, ma molto più intuitivo da usare nel caso comune.
find . -name 'nametosearch'o -inameper la distinzione tra maiuscole e minuscole. Sostituisci .con un percorso di directory per eseguire ricerche diverse dalla directory corrente. Ecco, questo è il 90% dei requisiti di un utente inesperto coperto senza nemmeno entrare in file traballanti. (Di solito uso find . -iname '*partialfilename*'e, se sto effettuando una ricerca /, utilizzo ciò find / -maxdepth 5 -iname '*partialname*'che riduce i tempi di ricerca trovando tutto ciò che mi interessa nel 90% delle volte. Lì, il 75% dei requisiti degli utenti intermedi.) :)
Un leggero inconveniente di Locate è che potrebbe non indicizzare l'area del file system a cui sei interessato. Sui sistemi desktop Debian, ad esempio Linux Mint 17.2, il file /etc/updatedb.conf è configurato per escludere determinate aree dalla considerazione , inclusi / tmp, / var / spool e /home/.ecryptfs.
Ignorare /home/.ecryptfs impedisce ai nomi di file nelle directory crittografate di essere esposti a utenti non autorizzati. Tuttavia, se la tua home directory è crittografata con ecryptfs, significa anche che la tua home directory non è indicizzata e quindi individuare non troverà mai nulla nella tua home directory. Questo potrebbe renderlo in gran parte inutile per te (lo fa per me). Oltre a non trovare risultati, il processo aggiornatob caricherà periodicamente il disco senza alcun vantaggio e potrebbe anche essere disabilitato se l'utente principale o unico del sistema.