Réponses:
locate(1)n’a qu’un seul gros avantage find(1): la vitesse.
find(1)a cependant de nombreux avantages par rapport à locate(1):
find(1)est primordial, remontant à la toute première version de AT & T Unix . Vous le trouverez même dans les Linux embarqués découpés via Busybox . C'est tout sauf universel.
locate(1)est beaucoup plus jeune que find(1). Le premier ancêtre de locate(1) n'est apparu qu'en 1983 , et il n'était pas largement disponible en tant que " locate" avant 1994, date à laquelle il a été adopté dans GNU findutils et dans 4.4BSD .
locate(1)est également non standard , donc il n’est pas installé par défaut partout. Certains systèmes d’exploitation de type POSIX ne l’offrent même pas en option et, s’il est disponible, les fonctionnalités que vous souhaitez implémenter peuvent manquer, car il n’existe pas de norme indépendante spécifiant le jeu de fonctionnalités minimum qui doit être disponible.
Il y a un de facto standard, étant BSDlocate(1) , mais qui est seulement parce que les deux autres saveurs principales de locatemettre en œuvre toutes ses options: -0, -c, -d, -i, -l, -m, -set -S. mlocatemet en œuvre des 6 options supplémentaires non dans BSD locate: -b, -e, -P, -q, --regexet -w. GNUlocate implémente ces six plus un autre quatre : -A, -D, -Eet -p. (J'ignore les alias et les différences mineures comme -?vs -hvs. --help)
Les BSD et Mac OS X sont livrés avec BSD locate.
La plupart des Linux sont fournis avec GNU locate, mais Red Hat Linuxes et Arch sont mlocateplutôt fournis . Debian n'installe pas non plus l'installation de base, mais propose les deux versions dans ses référentiels de paquets par défaut; si les deux sont installés en même temps, " locate" s'exécute mlocate.
Oracle est commercialisé mlocatesous Solaris depuis la 11.2 , publié en décembre 2014. Auparavant, il locaten'était pas installé par défaut sur Solaris. (Cela a sans doute été fait pour réduire l'incompatibilité des commandes de Solaris avec Oracle Linux , qui est basé sur Red Hat Enterprise Linux , qui utilise également mlocate.)
IBM AIX ne fonctionne toujours pas livré une version locate, au moins d'AIX 7.2 , sauf si vous installez GNU findutilsde la boîte à outils AIX pour les applications Linux .
HP-UX semble également faire défaut locatedans le système de base.
Les anciens "vrais" Unixes n'incluaient généralement pas d'implémentation de locate.
find(1)a une syntaxe d'expression puissante, avec de nombreuses fonctions, opérateurs booléens , etc.
find(1)peut sélectionner des fichiers avec plus que leur nom. Il peut sélectionner par:
Lorsque vous recherchez des fichiers par nom, vous pouvez effectuer une recherche à l'aide de la syntaxe de définition de fichier dans toutes les versions de find(1)GNU ou BSD, ou à l'aide d' expressions régulières .
Les versions actuelles de locate(1)modèles glob acceptent comme le findfait, mais BSD locatene fait pas du tout de regex. Si vous êtes comme moi et que vous devez utiliser différents types de machines, vous préférez utiliser le grepfiltrage pour développer une dépendance à -rou --regex.
locatebesoin de filtrer plus fort que findparce que ...
find(1)ne recherche pas nécessairement tout le système de fichiers. Vous le dirigez généralement vers un sous-répertoire, un parent contenant tous les fichiers sur lesquels vous souhaitez qu'il fonctionne. Le comportement typique d'une locate(1)implémentation est de créer tous les fichiers correspondant à votre modèle, de le grepfiltrer et de réduire son éruption à la taille.
(Astuce maléfique: locate /vous obtiendrez probablement une liste de tous les fichiers du système!)
Il existe des variantes de locate(1)type similaire slocate(1)qui limitent la sortie en fonction des autorisations de l'utilisateur, mais ce n'est pas la version par défaut de locatetout système d'exploitation principal.
find(1)peut faire des choses sur les fichiers qu'il trouve, en plus de simplement les trouver. Cet opérateur est le plus puissant et le plus largement supporté -exec, mais il en existe d'autres. Dans les récentes implémentations de recherche GNU et BSD, par exemple, vous avez les opérateurs -deleteet -execdir.
find(1) fonctionne en temps réel, donc sa sortie est toujours à jour.
Parce que locate(1)repose sur une base de données mise à jour plusieurs heures ou jours auparavant, sa sortie peut être obsolète. (Ceci est le problème de cache obsolète .) Cette pièce a deux faces:
locate peut nommer des fichiers qui n'existent plus.
GNU locateet mlocateont le -edrapeau pour le faire vérifier l’existence d’un fichier avant d’imprimer le nom de chaque fichier qu’il a découvert par le passé, mais cela réduit en partie l’ locateavantage de la rapidité et n’est pas disponible dans BSD locate.
locate ne nommera pas les fichiers créés depuis la dernière mise à jour de la base de données.
Vous apprenez à vous méfier un peu de la locatesortie, sachant que cela peut être faux.
Il existe des moyens de résoudre ce problème, mais je ne suis au courant d'aucune implémentation largement utilisée. Par exemple, il en existe rlocate, mais cela ne semble fonctionner avec aucun noyau Linux moderne.
find(1) n'a jamais plus de privilège que l'utilisateur qui l'exécute.
Parce qu’il locatefournit un service global à tous les utilisateurs d’un système, il souhaite que son updatedbprocessus soit exécuté de rootmanière à pouvoir afficher l’ensemble du système de fichiers. Cela conduit à un choix de problèmes de sécurité:
Exécuter en updatedbtant que root, mais rendre son fichier de sortie lisible par tout le monde, afin de locatepouvoir fonctionner sans privilèges spéciaux. Cela expose efficacement les noms de tous les fichiers du système à tous les utilisateurs. Cela peut constituer une violation de sécurité suffisante pour causer un problème réel.
BSD locateest configuré de cette manière sur Mac OS X et FreeBSD.
Ecrivez la base de données comme lisible uniquement par rootet créez la locate setuidracine pour pouvoir lire la base de données. Cela signifie qu’il faut locateeffectivement réimplémenter le système de permission du système d’exploitation pour qu’il ne vous montre pas les fichiers que vous ne pouvez pas voir normalement. Cela augmente également la surface d’attaque de votre système, risquant en particulier une attaque par escalade de la racine .
Créez un " locate" utilisateur ou groupe spécial pour posséder le fichier de base de données et marquez le locatebinaire comme setuid/setgidpour cet utilisateur / groupe afin qu'il puisse lire la base de données. Cela n'empêche pas les attaques d'élévation de privilèges par lui-même, mais cela atténue considérablement les dommages que l'on pourrait causer.
mlocateest configuré de cette manière sur Red Hat Enterprise Linux .
Cependant, vous avez toujours un problème, car si vous pouvez utiliser un débogueur locateou le dumper, vous pouvez accéder à des parties privilégiées de la base de données.
Je ne vois pas comment créer une commande véritablement "sécurisée" locate, à moins de l'exécuter séparément pour chaque utilisateur du système, ce qui annule en grande partie son avantage find(1).
En bout de ligne, les deux sont très utiles. locate(1)est préférable lorsque vous essayez simplement de trouver un fichier particulier par son nom, que vous savez exister, mais vous ne vous rappelez pas exactement où il se trouve. find(1)est préférable lorsque vous avez une zone ciblée à examiner ou lorsque vous avez besoin de l’un de ses nombreux avantages.
find -- "$dir" pas robuste ( $dirpeut être considéré comme un prédicat), aucun moyen de tester les attributs d'un lien symbolique, des problèmes de condition de concurrence critique ... Pour moi findet de locaterésoudre deux problèmes différents. Il existe de nombreux endroits où utiliser find n'est pas réaliste (comme des répertoires contenant des millions de fichiers). Locate est un système d'indexation limité aux noms de fichiers.
locateétaient à peu près fantastiques find / -type f | gzip > locate.gz, etzgrep "$1" <locate.gz
locateest dans le findutilspaquet, et son updatedbprogramme est implémenté en termes de find(1). Donc, dans ce sens, nécessitelocate(1) réellement . :) find(1)
find, locateetc. dans d' autres sections de sorte qu'il ne doit pas être là pour désambiguïser le même nom utilisé dans différentes sections de le manuel (par exemple unlink(1)vs unlink(2)), ceux d’entre nous habitués à la convention y voient une référence de page de manuel.
locateutilise une base de données prédéfinie, qui doit être mise à jour régulièrement, tout en findeffectuant une itération sur un système de fichiers pour localiser les fichiers.
Ainsi, locateest beaucoup plus rapide que find, mais peut être inexact si la base de données -peut être considérée comme un cache- n'est pas mise à jour (voir la updatedbcommande).
En outre, vous findpouvez offrir plus de granularité, car vous pouvez filtrer les fichiers en fonction de chaque attribut, tout en locateutilisant un modèle correspondant aux noms de fichier.
findn’est pas possible pour un utilisateur novice ou occasionnel d’utiliser Unix avec succès sans une lecture attentive de la page de manuel. Historiquement, certaines versions de findn'ont même pas choisi l' -printoption par défaut , ajoutant à l'hostilité de l'utilisateur.
locate est moins flexible, mais beaucoup plus intuitif à utiliser dans le cas courant.
find . -name 'nametosearch'ou -inameinsensible à la casse. Remplacez .par un chemin de répertoire pour rechercher un répertoire autre que le répertoire actuel. Cela représente 90% des besoins d’un utilisateur novice, sans même s’embarrasser de la globalisation de fichiers. (J'utilise généralement find . -iname '*partialfilename*'et si je cherche chez /, j'utilise find / -maxdepth 5 -iname '*partialname*'qui réduit le temps de recherche tout en trouvant tout ce qui m'intéresse 90% du temps. Là, 75% des besoins des utilisateurs intermédiaires.) :)
Un léger inconvénient de localise est qu’il peut ne pas indexer la zone du système de fichiers qui vous intéresse. Sur les systèmes de bureau Debian, par exemple Linux Mint 17.2, le fichier /etc/updatedb.conf est configuré pour exclure certaines zones de la considération. , y compris / tmp, / var / spool et /home/.ecryptfs.
Ignorer /home/.ecryptfs empêche les noms de fichiers des répertoires chiffrés d'être exposés à des utilisateurs non autorisés. Toutefois, si votre répertoire de base est crypté avec ecryptfs, cela signifie également que votre répertoire de base n’est pas indexé, et que localiser ne trouvera jamais rien dans votre répertoire de base. Cela pourrait le rendre en grande partie inutile pour vous (cela le fait pour moi). En plus de ne pas trouver de résultats, le processus updatedb chargera périodiquement votre disque sans aucun avantage et pourrait également être désactivé si vous êtes le principal ou l'unique utilisateur du système.