Respostas:
locate(1)tem apenas uma grande vantagem find(1): velocidade.
find(1), porém, tem muitas vantagens sobre locate(1):
find(1)é primordial, remonta à primeira versão do AT&T Unix . Você ainda o encontrará em Linuxs embutidos via Busybox . É tudo, menos universal.
locate(1)é muito mais jovem que find(1). O ancestral mais antigo de locate(1) não apareceu até 1983 , e não estava amplamente disponível como " locate" até 1994, quando foi adotado no GNU findutils e no 4.4BSD .
locate(1)também não é padrão , portanto, não é instalado por padrão em todos os lugares. Alguns sistemas operacionais do tipo POSIX nem o oferecem como opção e, onde está disponível, a implementação pode não ter os recursos desejados, porque não há um padrão independente especificando o conjunto mínimo de recursos que deve estar disponível.
Há uma de facto padrão, sendo BSDlocate(1) , mas isso é só porque os outros dois principais sabores de locateimplementar todas as suas opções: -0, -c, -d, -i, -l, -m, -s, e -S. mlocateimplementa 6 opções adicionais não em BSD locate: -b, -e, -P, -q, --regexe -w. GNUlocate implementa os seis mais outro quatro : -A, -D, -E, e -p. (Estou ignorando aliases e pequenas diferenças como -?vs -hvs. --help)
Os BSDs e o Mac OS X são enviados BSD locate.
A maioria dos Linux fornece GNU locate, mas o Red Hat Linux e o Arch fornecem mlocate. O Debian não instala em sua instalação base, mas oferece as duas versões em seus repositórios de pacotes padrão; se os dois estiverem instalados ao mesmo tempo, " locate" será executado mlocate.
A Oracle entrega o mlocateSolaris desde 11.2 , lançado em dezembro de 2014. Antes disso, locatenão era instalado por padrão no Solaris. (Presumivelmente, isso foi feito para reduzir a incompatibilidade de comandos do Solaris com o Oracle Linux , que é baseado no Red Hat Enterprise Linux , que também usa mlocate.)
O IBM AIX ainda não envia nenhuma versão locate, pelo menos a partir do AIX 7.2 , a menos que você instale o GNU a findutilspartir do AIX Toolbox for Linux Applications .
O HP-UX também parece faltar locateno sistema básico.
Unixes "reais" mais antigos geralmente não incluíam uma implementação de locate.
find(1)possui uma poderosa sintaxe de expressão, com muitas funções, operadores booleanos , etc.
find(1)pode selecionar arquivos por mais do que apenas um nome. Pode selecionar por:
Ao localizar arquivos pelo nome, você pode pesquisar usando a sintaxe de busca de arquivos em todas as versões find(1)ou nas versões GNU ou BSD, usando expressões regulares .
As versões atuais locate(1)aceitam padrões glob find, mas o BSD locatenão faz regexes. Se você é como eu e precisa usar vários tipos de máquinas, prefere a grepfiltragem a desenvolver uma dependência de -rou --regex.
locateprecisa de filtragem forte mais do que findfaz porque ...
find(1)não necessariamente pesquisa o sistema de arquivos inteiro. Você normalmente o aponta para um subdiretório, um pai que contém todos os arquivos nos quais deseja que ele funcione. O comportamento típico de uma locate(1)implementação é vomitar todos os arquivos correspondentes ao seu padrão, deixando-o para grepfiltragem e, assim, diminuindo sua erupção.
(Dica: locate /provavelmente você receberá uma lista de todos os arquivos no sistema!)
Existem variantes locate(1)semelhantes slocate(1)que restringem a saída com base nas permissões do usuário, mas essa não é a versão padrão de locatenenhum sistema operacional principal.
find(1)pode fazer coisas com os arquivos que encontrar, além de apenas encontrá-los. O operador mais poderoso e amplamente suportado é esse -exec, mas existem outros. Em recentes GNU e BSD, encontre implementações, por exemplo, você tem os operadores -deletee -execdir.
find(1) é executado em tempo real, portanto, sua saída está sempre atualizada.
Como locate(1)conta com um banco de dados atualizado horas ou dias no passado, sua saída pode estar desatualizada. (Esse é o problema do cache antigo .) Essa moeda tem dois lados:
locate pode nomear arquivos que não existem mais.
GNU locatee mlocatetenha o -esinalizador para verificar a existência de arquivos antes de imprimir o nome de cada arquivo descoberto no passado, mas isso tira algumas locatevantagens da velocidade e não está disponível no BSD locate.
locate falhará ao nomear arquivos que foram criados desde a última atualização do banco de dados.
Você aprende a desconfiar um pouco da locateprodução, sabendo que pode estar errado.
Existem maneiras de resolver esse problema, mas não conheço nenhuma implementação em uso generalizado. Por exemplo, existe rlocate, mas parece não funcionar contra nenhum kernel Linux moderno.
find(1) nunca tem mais privilégios do que o usuário que está executando.
Como locatefornece um serviço global para todos os usuários em um sistema, ele deseja que seu updatedbprocesso seja executado, rootpara que possa ver todo o sistema de arquivos. Isso leva a uma escolha de problemas de segurança:
Execute updatedbcomo root, mas torne seu arquivo de saída legível pelo mundo para que ele locatepossa ser executado sem privilégios especiais. Isso expõe efetivamente os nomes de todos os arquivos no sistema para todos os usuários. Isso pode ser uma violação de segurança suficiente para causar um problema real.
O BSD locateé configurado dessa maneira no Mac OS X e no FreeBSD.
Escreva o banco de dados como legível apenas por roote faça locate setuidroot para que ele possa ler o banco de dados. Isso significa que locateefetivamente é necessário reimplementar o sistema de permissão do sistema operacional para que ele não mostre os arquivos que você normalmente não pode ver. Também aumenta a superfície de ataque do seu sistema, arriscando especificamente um ataque de escalação de raiz .
Crie um locateusuário ou grupo " " especial para possuir o arquivo de banco de dados e marque o locatebinário como setuid/setgidpara esse usuário / grupo para que ele possa ler o banco de dados. Isso não evita ataques de escalação de privilégios por si só, mas atenua bastante o dano que poderia causar.
mlocateestá configurado desta maneira no Red Hat Enterprise Linux .
No entanto, você ainda tem um problema, porque se você pode usar um depurador locateou fazer com que ele despeje o núcleo, pode obter partes privilegiadas do banco de dados.
Não vejo uma maneira de criar um locatecomando verdadeiramente "seguro" , sem executá-lo separadamente para cada usuário do sistema, o que nega grande parte de sua vantagem find(1).
Bottom line, ambos são muito úteis. locate(1)é melhor quando você está apenas tentando encontrar um arquivo específico por nome, que você sabe que existe, mas não se lembra exatamente onde ele está. find(1)é melhor quando você tem uma área focada para examinar ou quando precisa de uma de suas muitas vantagens.
find -- "$dir" não robusta ( $dirpode ser usada como predicado), nenhuma maneira de testar os atributos de um link simbólico, problemas de condição de corrida ... Para mim, finde locateresolver dois problemas diferentes. Há muitos lugares em que o uso do find não é realista (como diretórios contendo milhões de arquivos). localize é um sistema de indexação limitado a nomes de arquivos.
locatefoi de aproximadamente someting como find / -type f | gzip > locate.gzezgrep "$1" <locate.gz
locateestá no findutilspacote, e seu updatedbprograma é implementado em termos de find(1). Então, nesse sentido, locate(1)realmente requer find(1) . :)
find, locateetc. em outras seções para que ele não tem que estar lá para disambiguate o mesmo nome usado em diferentes seções o manual (por exemplo, unlink(1)vs unlink(2)), aqueles de nós acostumados à convenção veem isso como uma referência da página de manual.
locateusa um banco de dados pré-construído, que deve ser atualizado regularmente, enquanto findrepete sobre um sistema de arquivos para localizar arquivos.
Portanto, locateé muito mais rápido que find, mas pode ser impreciso se o banco de dados - pode ser visto como um cache - não for atualizado (consulte o updatedbcomando).
Além disso, findpode oferecer mais granularidade, pois é possível filtrar arquivos por todos os atributos, enquanto locateusa um padrão correspondente aos nomes dos arquivos.
findnão é possível para um usuário iniciante ou ocasional do Unix usar com êxito sem uma leitura cuidadosa da página de manual. Historicamente, algumas versões findnem sequer assumiram o padrão da -printopção, aumentando a hostilidade do usuário.
locate é menos flexível, mas muito mais intuitivo de usar no caso comum.
find . -name 'nametosearch', ou -inamepara não diferenciar maiúsculas de minúsculas. Substitua .por um caminho de diretório para procurar outro diretório que não o atual. Lá, 90% dos requisitos de um usuário iniciante são cobertos, mesmo sem entrar no globbing de arquivos. (Geralmente, eu usaria find . -iname '*partialfilename*'e, se estou pesquisando /, uso o find / -maxdepth 5 -iname '*partialname*'que reduz o tempo de pesquisa e encontro tudo o que me interessa 90% das vezes. Lá, 75% dos requisitos de usuários intermediários.) :)
Uma pequena desvantagem da localização é que ela pode não estar indexando a área do sistema de arquivos em que você está interessado. Nos sistemas desktop Debian, por exemplo, Linux Mint 17.2, o arquivo /etc/updatedb.conf está configurado para excluir determinadas áreas da consideração , incluindo / tmp, / var / spool e /home/.ecryptfs.
Ignorar /home/.ecryptfs impede que nomes de arquivos em diretórios criptografados sejam expostos a usuários não autorizados. No entanto, se o diretório inicial estiver criptografado com ecryptfs, isso também significa que o diretório inicial não está indexado e, portanto, a localização nunca encontrará nada no diretório inicial. Isso pode torná-lo praticamente inútil para você (isso é para mim). Além de não encontrar resultados, o processo updatedb carregará seu disco periodicamente sem nenhum benefício e poderá ser desativado se você for o principal ou único usuário do sistema.