Antworten:
locate(1)hat nur einen großen Vorteil gegenüber find(1): Geschwindigkeit.
find(1)hat jedoch viele Vorteile gegenüber locate(1):
find(1)ist ursprünglich und geht auf die allererste Version von AT & T Unix zurück . Sie werden es sogar in abgespeckten Embedded-Linuxes über Busybox finden . Es ist alles andere als universell.
locate(1)ist viel jünger als find(1). Der früheste Vorfahre von locate(1) erschien erst 1983 und war locatebis 1994, als er in GNU findutils und 4.4BSD übernommen wurde, nicht als " " weit verbreitet .
locate(1)ist auch nicht standard , daher wird es nicht überall standardmäßig installiert. Einige POSIX-Betriebssysteme bieten es nicht einmal als Option an. Wenn es verfügbar ist, fehlen der Implementierung möglicherweise die gewünschten Funktionen, da es keinen unabhängigen Standard gibt, der die Mindestfunktionsmenge angibt, die verfügbar sein muss.
Es ist ein De - facto - Standard, wobei BSDlocate(1) , aber das ist nur , weil die beiden anderen Haupt Aromen von locateallen seinen Möglichkeiten implementieren: -0, -c, -d, -i, -l, -m, -s, und -S. mlocatezusätzliche Optionen implementiert 6 in BSD nicht locate: -b, -e, -P, -q, --regexund -w. GNUlocate implementiert die six plus weitere vier : -A, -D, -E, und -p. (Ich ignoriere Aliase und kleinere Unterschiede wie -?vs -hvs. --help)
Die BSDs und Mac OS X enthalten BSD locate.
Die meisten Linuxes liefern GNU aus locate, aber mlocatestattdessen werden Red Hat Linuxes und Arch ausgeliefert . Debian installiert auch nicht in seiner Basisinstallation, sondern bietet beide Versionen in seinen Standard-Paket-Repositories an. " locate" Wenn beide gleichzeitig installiert sind, wird ausgeführt mlocate.
Oracle wird mlocatein Solaris seit Version 11.2 ausgeliefert , die im Dezember 2014 veröffentlicht wurde. Zuvor war Oracle unter Solaris locatenicht standardmäßig installiert. (Vermutlich wurde dies getan, um die Inkompatibilität von Solaris-Befehlen mit Oracle Linux zu verringern , das auf Red Hat Enterprise Linux basiert , das ebenfalls verwendet mlocate.)
IBM AIX mitliefert noch keine Version von locate, zumindest ab AIX 7.2 , es sei denn , Sie GNU installieren findutilsvon der für Linux - Anwendungen AIX Toolbox .
HP-UX scheint auch im Basissystem zu fehlen locate.
Ältere "echte" Unixe enthielten im Allgemeinen keine Implementierung von locate.
find(1)hat eine leistungsstarke Ausdruckssyntax mit vielen Funktionen, Booleschen Operatoren usw.
find(1)Dateien können nicht nur nach Namen ausgewählt werden. Es kann wählen durch:
Wenn Sie Dateien nach Namen suchen, können Sie in allen Versionen von oder in GNU- oder BSD-Versionen mithilfe regulärer Ausdrücke mithilfe der File-Globbing-Syntax suchen .find(1)
Aktuelle Versionen locate(1)akzeptieren Glob-Patterns genauso findwie BSD, aber es werden locateüberhaupt keine regulären Ausdrücke verwendet. Wenn Sie wie ich sind und eine Vielzahl von Maschinentypen verwenden müssen, ziehen Sie das grepFiltern dem Entwickeln einer Abhängigkeit von -roder vor --regex.
locatemuss stärker gefiltert werden als findweil ...
find(1)Durchsucht nicht unbedingt das gesamte Dateisystem. Sie verweisen normalerweise auf ein Unterverzeichnis, ein übergeordnetes Verzeichnis, das alle Dateien enthält, mit denen Sie arbeiten möchten. Das typische Verhalten für eine locate(1)Implementierung besteht darin, alle Dateien, die Ihrem Muster entsprechen, auszuspucken, zu grepfiltern und so den Ausbruch auf die Größe zu reduzieren.
(Böser Tipp: Sie erhalten locate /wahrscheinlich eine Liste aller Dateien auf dem System!)
Es gibt locate(1)ähnliche Varianten, slocate(1)die die Ausgabe basierend auf den Benutzerberechtigungen einschränken. Dies ist jedoch nicht die Standardversion locateeines größeren Betriebssystems.
find(1)kann Dinge mit Dateien tun , die es findet, und sie auch nur finden. Der mächtigste und am meisten unterstützte Operator ist -exec, aber es gibt noch andere. In neueren GNU- und BSD-Suchimplementierungen haben Sie beispielsweise die Operatoren -deleteund -execdir.
find(1) Läuft in Echtzeit, sodass die Ausgabe immer auf dem neuesten Stand ist.
Da locate(1)eine Datenbank verwendet wird, die in der Vergangenheit über Stunden oder Tage aktualisiert wurde, kann ihre Ausgabe veraltet sein. (Dies ist das Problem mit dem veralteten Cache .) Diese Münze hat zwei Seiten:
locate kann nicht mehr existierende Dateien benennen.
GNU locateund lassen mlocatedas -eFlag prüfen, ob eine Datei existiert, bevor der Name jeder Datei, die es in der Vergangenheit entdeckt hat, ausgedruckt wird. Dies verschlechtert jedoch den locateGeschwindigkeitsvorteil und ist außerdem in BSD nicht verfügbar locate.
locate kann keine Dateien benennen, die seit der letzten Datenbankaktualisierung erstellt wurden.
Du lernst, etwas misstrauisch gegenüber locateOutput zu sein, weil du weißt, dass es falsch sein kann.
Es gibt Möglichkeiten, dieses Problem zu lösen, mir ist jedoch keine Implementierung in weit verbreitetem Umfang bekannt. Zum Beispiel gibt es rlocate, aber es scheint nicht gegen einen modernen Linux-Kernel zu funktionieren.
find(1) hat nie mehr Rechte als der Benutzer, der es ausführt.
Da locateein globaler Dienst für alle Benutzer eines Systems bereitgestellt wird, soll der updatedbProzess rootso ausgeführt werden, dass das gesamte Dateisystem angezeigt wird. Dies führt zu einer Reihe von Sicherheitsproblemen:
Führen Sie updatedbals root, aber seine Ausgabedatei Welt lesbar machen , so locatekann ohne besondere Privilegien auszuführen. Auf diese Weise werden die Namen aller Dateien im System allen Benutzern angezeigt. Dies kann als Sicherheitsverletzung ausreichen, um ein echtes Problem zu verursachen.
BSD locateist unter Mac OS X und FreeBSD auf diese Weise konfiguriert.
Schreiben Sie die Datenbank so root, dass sie nur von gelesen werden kann , und erstellen Sie locate setuidroot, damit sie die Datenbank lesen kann. Dies bedeutet, dass locatedas Berechtigungssystem des Betriebssystems neu implementiert werden muss, damit keine Dateien angezeigt werden, die Sie normalerweise nicht sehen können. Es erhöht auch die Angriffsfläche Ihres Systems und riskiert insbesondere einen Root-Eskalationsangriff .
Erstellen Sie einen speziellen locateBenutzer " " oder eine spezielle Gruppe, der bzw. der die Datenbankdatei gehört, und markieren Sie die locateBinärdatei setuid/setgidfür diesen Benutzer / diese Gruppe, damit die Datenbank gelesen werden kann. Dies verhindert keine Eskalationsangriffe durch Privilegien, verringert jedoch den Schaden, den diese Angriffe anrichten können, erheblich.
mlocatewird unter Red Hat Enterprise Linux auf diese Weise konfiguriert .
Sie haben jedoch immer noch ein Problem, denn wenn Sie einen Debugger verwenden locateoder dafür sorgen können, dass er den Kern auslagert, können Sie auf privilegierte Teile der Datenbank zugreifen.
Ich sehe keine Möglichkeit, einen wirklich "sicheren" locateBefehl zu erstellen, wenn man ihn nicht für jeden Benutzer auf dem System einzeln ausführt, was einen Großteil seines Vorteils gegenüber dem System zunichte macht find(1).
Unterm Strich sind beide sehr nützlich. locate(1)ist besser, wenn Sie nur versuchen, eine bestimmte Datei anhand ihres Namens zu finden, von der Sie wissen, dass sie existiert, aber Sie können sich nicht erinnern, wo genau sie sich befindet. find(1)ist besser, wenn Sie einen bestimmten Bereich untersuchen müssen oder wenn Sie einen der vielen Vorteile benötigen.
find -- "$dir" nicht robust ( $dirkann als Prädikat betrachtet werden), keine Möglichkeit, die Attribute eines Symlinks zu testen, Probleme mit den Rennbedingungen ... findund locatezwei verschiedene Probleme ansprechen. Es gibt viele Stellen, an denen die Verwendung von find nicht realistisch ist (z. B. Verzeichnisse mit Millionen von Dateien). locate ist ein Indizierungssystem, das auf Dateinamen beschränkt ist.
locatewaren ungefähr so find / -type f | gzip > locate.gz, undzgrep "$1" <locate.gz
locateist im findutilsPaket enthalten, und sein updatedbProgramm ist in Bezug auf implementiert find(1). Also in diesem Sinne locate(1)eigentlich benötigt find(1) . :)
find, locateetc. in anderen Bereichen , so dass es nicht dort zu sein hat den gleichen Namen in verschiedenen Abschnitten verwendet , um Mehrdeutigkeiten Im Handbuch (z. B. unlink(1)vs unlink(2)) sehen diejenigen, die an die Konvention gewöhnt sind, dies als Manpage-Referenz.
locateverwendet eine vorgefertigte Datenbank, die regelmäßig aktualisiert werden sollte, während findüber ein Dateisystem nach Dateien gesucht wird.
Somit locateist viel schneller als find, kann aber ungenau sein , wenn die Datenbank als ein cache- gesehen werden -kann nicht aktualisiert wird (siehe updatedbBefehl).
Auch findkann mehr Granularität bieten, wie Sie Dateien von jedem Attribute davon filtern können, während locateein Muster gegen Dateinamen angepasst verwendet.
findist für einen Anfänger oder gelegentlichen Benutzer von Unix nicht möglich, ohne sorgfältige Durchsicht der Manpage erfolgreich zu verwenden. In der Vergangenheit haben einige Versionen von finddie -printOption nicht einmal standardmäßig aktiviert , was die Benutzerfeindlichkeit erhöht.
locate ist weniger flexibel, aber im allgemeinen Fall weitaus intuitiver zu bedienen.
find . -name 'nametosearch', oder -inamefür Groß- und Kleinschreibung. Ersetzen Sie .durch einen Verzeichnispfad, um nach einem anderen Verzeichnis als dem aktuellen zu suchen. Dort werden 90% der Anforderungen eines unerfahrenen Benutzers abgedeckt, ohne überhaupt mit dem Globeing von Dateien befasst zu sein. (Ich würde im Allgemeinen verwenden find . -iname '*partialfilename*'und wenn ich von suche /, verwende ich, find / -maxdepth 5 -iname '*partialname*'was die Suchzeit verkürzt, während ich in 90% der Fälle alles finde, was mich interessiert. Dort sind 75% der Anforderungen für fortgeschrittene Benutzer.) :)
Ein kleiner Nachteil von locate ist, dass es möglicherweise nicht den Bereich des Dateisystems indiziert, an dem Sie interessiert sind. Auf Debian-Desktopsystemen, zum Beispiel Linux Mint 17.2, ist die Datei /etc/updatedb.conf so konfiguriert, dass bestimmte Bereiche von der Betrachtung ausgeschlossen werden , einschließlich / tmp, / var / spool und /home/.ecryptfs.
Das Ignorieren von /home/.ecryptfs verhindert, dass Dateinamen in verschlüsselten Verzeichnissen nicht autorisierten Benutzern zugänglich gemacht werden. Wenn Ihr Basisverzeichnis jedoch mit ecryptfs verschlüsselt ist, bedeutet dies auch, dass Ihr Basisverzeichnis nicht indiziert ist und locate daher niemals etwas in Ihrem Basisverzeichnis findet. Dies könnte es für Sie zum größten Teil unbrauchbar machen (für mich). Zusätzlich dazu, dass keine Ergebnisse gefunden werden, lädt der aktualisierte Prozess Ihre Festplatte regelmäßig, ohne dass dies von Nutzen ist. Er kann auch deaktiviert werden, wenn Sie der Hauptbenutzer oder der einzige Benutzer des Systems sind.