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)
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.)
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 locatesetuidracine 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.
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.
Désolé, j'ai oublié le paragraphe "slocate". rlocate résout le problème du cache obsolète . Vous voudrez peut-être mentionner quelques-unes des bizarreries de find, telles que 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.
Stéphane Chazelas
2
Les premières implémentations de locateétaient à peu près fantastiques find / -type f | gzip > locate.gz, etzgrep "$1" <locate.gz
F. Hauri
@ F.Hauri: trivia intéressant. Voici plus: GNU 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)
Warren Young
1
@WarrenYoung pourquoi y a-t-il une référence constante à foo (1) au lieu de foo? Existe-t-il différentes versions, etc. de foo?
Noisette à propos de natty
4
@nuttyaboutnatty: C'est une convention ancienne dans les manuels Unix, ce qui signifie la section manuelle 1. Il est vrai qu'il n'y a pas 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.
Warren Young
35
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.
D'autre part, Locate doit gérer une base de données et s'exécuter périodiquement. Je l'ai donc désactivée sur tous les serveurs Linux situés sur notre réseau privé.
Rui F Ribeiro
2
Qu'est-ce qui est difficile? 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.) :)
Wildcard
2
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.
Réponses:
locate(1)n’a qu’un seul gros avantagefind(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 quefind(1). Le premier ancêtre delocate(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 BSD
locate(1), mais qui est seulement parce que les deux autres saveurs principales delocatemettre en œuvre toutes ses options:-0,-c,-d,-i,-l,-m,-set-S.mlocatemet en œuvre des 6 options supplémentaires non dans BSDlocate:-b,-e,-P,-q,--regexet-w. GNUlocateimplé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 sontmlocateplutô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écutemlocate.Oracle est commercialisé
mlocatesous Solaris depuis la 11.2 , publié en décembre 2014. Auparavant, illocaten'é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 égalementmlocate.)IBM AIX ne fonctionne toujours pas livré une version
locate, au moins d'AIX 7.2 , sauf si vous installez GNUfindutilsde 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 lefindfait, mais BSDlocatene 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 legrepfiltrage pour développer une dépendance à-rou--regex.locatebesoin de filtrer plus fort quefindparce 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'unelocate(1)implémentation est de créer tous les fichiers correspondant à votre modèle, de legrepfiltrer 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 similaireslocate(1)qui limitent la sortie en fonction des autorisations de l'utilisateur, mais ce n'est pas la version par défaut delocatetout 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:locatepeut nommer des fichiers qui n'existent plus.GNU
locateetmlocateont 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 BSDlocate.locatene 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 sonupdatedbprocessus soit exécuté derootmaniè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 delocatepouvoir 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 lalocatesetuidracine pour pouvoir lire la base de données. Cela signifie qu’il fautlocateeffectivement 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 lelocatebinaire commesetuid/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 avantagefind(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.la source
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 moifindet delocateré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 fantastiquesfind / -type f | gzip > locate.gz, etzgrep "$1" <locate.gzlocateest dans lefindutilspaquet, et sonupdatedbprogramme est implémenté en termes defind(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 exempleunlink(1)vsunlink(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 enfindeffectuant une itération sur un système de fichiers pour localiser les fichiers.Ainsi,
locateest beaucoup plus rapide quefind, mais peut être inexact si la base de données -peut être considérée comme un cache- n'est pas mise à jour (voir laupdatedbcommande).En outre, vous
findpouvez offrir plus de granularité, car vous pouvez filtrer les fichiers en fonction de chaque attribut, tout enlocateutilisant un modèle correspondant aux noms de fichier.la source
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 defindn'ont même pas choisi l'-printoption par défaut , ajoutant à l'hostilité de l'utilisateur.locateest moins flexible, mais beaucoup plus intuitif à utiliser dans le cas courant.la source
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éralementfind . -iname '*partialfilename*'et si je cherche chez/, j'utilisefind / -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.
la source