найти и найти: использование, плюсы и минусы друг друга

В системах Linux и Unix существуют две общие команды поиска: locate и find .

Каковы плюсы и минусы каждого? Когда у кого-то есть преимущество над другим?

112 голосов | спросил m0nhawk 3 Jpm1000000pmThu, 03 Jan 2013 21:13:57 +040013 2013, 21:13:57

4 ответа


150

locate(1) имеет только одно большое преимущество перед find(1): speed.

find(1) имеет many преимущества над locate(1):

  • find(1) является primordial, возвращается к самой первой версии AT & T Unix . Вы даже найдете его в вырезанных встроенных Linuxes через Busybox . Это почти универсально.

    locate(1) намного моложе, чем find(1). Самый ранний предок locate(1) в GNU findutils и в 4.4BSD .

  • locate также нестандартный , поэтому он по умолчанию не установлен по умолчанию. Некоторые операционные системы типа POSIX даже не предлагают его в качестве опции, и там, где он доступен, реализация может быть недостаточной для функций, потому что нет независимого стандарта, указывающего минимальный набор функций, который должен быть доступен.

    Существует стандарт de facto , являющийся BSD locate(1) , но это связано только с тем, что два других основных свойства locate(1) реализуют все его параметры: locate, -0, -c, -d, -i, -l, -m и -s. -S реализует 6 дополнительных параметров не в BSD mlocate: -b, locate, -b, -e, -P и -q. GNU --regex реализует эти шесть плюс еще четыре : -w, locate, -A и -D. (Я игнорирую псевдонимы и незначительные различия, такие как -E vs -p vs -?.)

    BSDs и Mac OS X ship BSD -h.

    Большинство Linuxes отправляют GNU --help, но Red Hat Linuxes и Arch отправляют locate вместо этого. Debian не устанавливает ни в своей базовой установке, но предлагает обе версии в своих репозиториях по умолчанию; если оба установлены сразу, «locate» запускает mlocate.

    Oracle отправляет locate в Solaris с 11.2 , выпущен в декабре 2014 года. До этого, mlocate не был установлен по умолчанию в Solaris. (Предположительно, это было сделано для уменьшения несовместимости команды Solaris с Oracle Linux , которая на основе Red Hat Enterprise Linux , который также использует mlocate.)

    IBM AIX по-прежнему не отправляет какую-либо версию locate , по крайней мере, с AIX 7.2 , если вы не установили GNU mlocate из AIX Toolbox для Linux-приложений .

    HP-UX также появляется , чтобы не найти locate в базовой системе.

    Старые «реальные» Unixes обычно не включали реализацию findutils.

  • locate имеет мощный синтаксис выражений с множеством функций Булевы операторы и т. Д.

  • locate может выбирать файлы не только для имени. Он может выбирать:

    • возраст
    • размер литий>
    • владелец
    • тип файла
    • Отметка времени
    • разрешения
    • глубину внутри поддерева ...
  • При поиске файлов по имени вы можете выполнить поиск с помощью синтаксис globaling во всех версиях find(1), или в версиях GNU или BSD, используя регулярные выражения .

    Текущие версии find(1) принимают шаблоны glob как find(1), но BSD locate(1) не выполняет регулярных выражений вообще. Если вы похожи на меня и должны использовать различные типы машин, вы предпочитаете использовать фильтрацию find для разработки зависимости от locate или grep.

    -r требуется сильная фильтрация более чем --regex, потому что ...

  • locate не обязательно ищет всю файловую систему. Обычно вы указываете его в подкаталоге, родитель, содержащий все файлы, которые вы хотите, чтобы он работал. Типичное поведение для реализации find заключается в том, чтобы отбросить все файлы, соответствующие вашему шаблону, оставив его в find(1), и таким образом сократить его извержение до размера.

    (Evil tip: locate(1), вероятно, вы получите список всех файлов в системе!)

    Существуют варианты grep, например locate ., которые ограничивают вывод на основе пользовательских разрешений, но это не стандартная версия locate(1) в любой основной операционной системе.

  • slocate(1) может делать вещи в найденных файлах, а не просто находить их. Самый мощный и широко поддерживаемый такой оператор - locate, но есть и другие. В последних реализациях GNU и BSD, например, у вас есть операторы find(1) и -exec.

  • -delete работает в режиме реального времени, поэтому его вывод всегда обновляется.

    Поскольку -execdir полагается на обновленную базу данных часов или дней в прошлом, ее выход может быть устаревшим. (Это проблема устаревших кешей .) Эта монета имеет две стороны:

    1. find(1) можно назвать файлы, которые больше не существуют.

      GNU locate(1) и locate имеют флаг locate, чтобы он проверял существование файла перед тем, как распечатать имя каждого найденного файла в прошлом, но это избавляет от некоторых преимуществ mlocate и не доступно в BSD -e.

    2. locate не сможет назвать файлы, созданные с момента последнего обновления базы данных.

    Вы научитесь быть несколько недоверчивыми к выводу locate, зная, что это может быть неправильно.

    Есть способы решить эту проблему, но я не знаю о какой-либо реализации в широком использовании. Например, существует locate , но он появляется , чтобы не работать против какого-либо современного ядра Linux.

  • locate никогда не имеет больше привилегий, чем пользователь, выполняющий его.

    Поскольку rlocate предоставляет глобальную услугу всем пользователям в системе, он хочет, чтобы процесс find(1) выполнялся как locate, чтобы он мог см. всю файловую систему. Это приводит к выбору проблем безопасности:

    1. Запустите updatedb как root, но сделайте свой выходной файл доступным для чтения, чтобы root мог работать без особых привилегий. Это эффективно предоставляет имена всех файлов в системе всем пользователям. Это может быть достаточно нарушения безопасности, чтобы вызвать реальную проблему.

      BSD updatedb настроен таким образом на Mac OS X и FreeBSD.

    2. Запишите базу данных как прочитанную только с помощью locate и сделайте locate root root , чтобы он мог читать базу данных. Это означает, что locate эффективно должен переопределить систему разрешения ОС, чтобы она не показывала файлы, которые вы обычно не видите. Он также увеличивает поверхность атаки вашей системы, в частности, рискуя атака с помощью root escalation .

    3. Создайте специальный «setuid» для пользователя или группы для хранения файла базы данных и пометьте locate двоичный код как locate для этого user /group, чтобы он мог читать базу данных. Это не предотвращает самовыражения эскалации привилегий, но это значительно уменьшает ущерб, который может нанести ущерб.

      locate настроен таким образом на Red Hat Enterprise Linux .

      У вас все еще есть проблема, потому что если вы можете использовать отладчик в setuid/setgid или вызвать его dump core вы можете получить привилегированные части базы данных.

    Я не вижу способа создать действительно «безопасную» команду mlocate, не запуская ее отдельно для каждого пользователя в системе, что отрицает большую часть ее преимущества перед locate.

Нижняя линия, обе очень полезны. locate лучше, когда вы просто пытаетесь найти определенный файл по имени, который, как вы знаете, существует, но вы просто не помните, где именно. find(1) лучше, когда у вас есть сфокусированная область для изучения или когда вам нужно какое-либо из ее многочисленных преимуществ.

ответил Warren Young 3 Jpm1000000pmThu, 03 Jan 2013 21:36:28 +040013 2013, 21:36:28
29

locate использует предварительно созданную базу данных, которая должна регулярно обновляться, а find выполняет итерацию по файловой системе для поиска файлов.

Таким образом, locate намного быстрее, чем find, но может быть неточным, если база данных, которую можно рассматривать как кэш, не обновляется (см. updatedb).

Кроме того, find может предложить больше детализации, поскольку вы можете фильтровать файлы по каждому атрибуту, а locate использует шаблон, сопоставленный с именами файлов.

ответил user435943 3 Jpm1000000pmThu, 03 Jan 2013 21:36:21 +040013 2013, 21:36:21
6

find невозможно для успешного использования новичком или случайным пользователем Unix без тщательного прочтения справочной страницы. Исторически, некоторые версии find даже не устанавливали параметр -print, добавляя к враждебности пользователя.

locate менее гибкий, но гораздо более интуитивно понятный для использования в общем случае.

ответил Russell Borogove 4 Jam1000000amFri, 04 Jan 2013 05:03:08 +040013 2013, 05:03:08
1

Небольшой недостаток локации заключается в том, что он может не индексировать область интересующей вас файловой системы. В настольных системах Debian, например Linux Mint 17.2, файл /etc/updatedb.conf настроен на исключение определенных области от рассмотрения, включая /tmp, /var /spool и /home/.ecryptfs.

Игнорирование /home/.ecryptfs предотвращает доступ к именам файлов в зашифрованных каталогах для неавторизованных пользователей. Однако, если ваш домашний каталог зашифрован с помощью ecryptfs, это также означает, что ваш домашний каталог не проиндексирован, и поиск поэтому никогда не найдет ничего в вашем домашнем каталоге. Это может сделать его в значительной степени бесполезным для вас (это для меня). В дополнение к тому, чтобы не найти результаты, процесс updatedb будет периодически загружать ваш диск без каких-либо преимуществ и также может быть отключен, если вы являетесь основным или единственным пользователем системы.

ответил Jim 12 SatEurope/Moscow2015-12-12T13:30:14+03:00Europe/Moscow12bEurope/MoscowSat, 12 Dec 2015 13:30:14 +0300 2015, 13:30:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132