В операционных системах семейства Linux все объекты ОС: и данные, и управляющие элементы - являются файлами в файловой системе. Поэтому поиск файлов становится очень важной задачей. И если опытные пользователи уже знают, что и где находится, то для новичков будет очень полезным узнать, как найти местоположение того или иного файла, будь то программа, изображение или документ.
В Linux существует множество способов поиска, как в графическом интерфейсе, так и через командную строку. В сегодняшней статье мы разберём, как выполнять поиск файла в Linux с помощью всех этих средств. Но начнём с программ, у которых есть графический интерфейс.
Содержание статьи:
Поиск файла в Linux через графический интерфейс
1. Главное меню системы
Главное меню операционной системы позволяет, как правило, не только запускать программы, но и искать их, а также искать файлы. Такая возможность есть как в Gnome, так и в KDE. В главном меню Gnome вы можете ввести нужную фразу для поиска:
Но у такого поиска есть значительный недостаток. Он рассчитан больше на поиск программ, а не на поиск файлов, поэтому ищет только в домашней папке и не углубляется далеко в файловую систему.
2. Файловые менеджеры
Большинство файловых менеджеров тоже предоставляют возможности поиска файлов, в том числе Dolphin и Nautilus. Здесь вы можете выбрать папку, в которой будет выполняться поиск, а также настроить дополнительные параметры поиска. В Nautilus для запуска поиска вам достаточно нажать кнопку со значком лупы, а потом ввести данные в строку поиска. Например, найдём все фото, сделанные 18 ноября.
Открыв стрелочку дополнительных параметров можно выбрать период, за который был создан интересующий нас документ, а также тип документа.
В качестве поискового запроса можно использовать символы подстановки: ? и *. Но для более точного поиска придётся использовать сторонние программы.
3. Gnome Search
Утилита Gnome Search по умолчанию поставляется не всегда, но вы можете установить её из центра приложений или через официальные репозитории. Она предоставляет такие же возможности, как и файловый менеджер, плюс здесь можно искать по содержимому файлов, что иногда очень удобно.
4. SearchMonkey
Следующая программа в нашем списке - SearchMonkey. Она позволяет искать файлы по регулярным выражениям. Здесь тоже можно выполнять поиск файла, как по имени, так и по содержимому фала, можно выбрать диапазон дат и так далее. Но основное преимущество этой программы - возможность везде использовать регулярные выражения.
5. Recoll
Если вам приходится работать с большой библиотекой текстовой информации и искать данные по содержимому файла, то вам будет полезна утилита Recoll. Это полноценный поисковый движок для поиска документов. Установить программу можно из официальных репозиториев:
sudo apt install recoll
Сразу же после запуска она предложит вам создать индекс документов, которые есть в вашем домашнем каталоге.
И только после создания индекса вы сможете выполнять по нему поиск. Далее, вам будет достаточно ввести запрос, например Wi-Fi, и вы увидите все файлы, которые содержат это слово с примерами вхождений, отсортированные по релевантности:
Для работы с большим количеством текстовых данных это может быть очень удобно. Программа понимает множество офисных форматов, среди которых pdf, djvu, doc, docx, odf, а также умеет находить такие файлы в архивах.
Поиск файлов в Linux через терминал
Если графические утилиты рассчитаны на работу обычного пользователя и поиск в домашней папке, то консольные программы предоставляют более гибкие возможности поиск для всех файлов, включая системные и виртуальные.
1. find
Самая часто используемая команда поиска файла в Linux на данный момент - это find. Она имеет множество возможностей: вы можете искать файлы по имени, дате изменения, создания, использовать регулярные выражения и маски, выполнять определённые действия для найденных файлов, настраивать глубину поиска и многое другое. Например, найдем все файлы, которые начинаются на "Снимок" в папке ~/Изображения:
find ~/Изображения -iname "Снимок*"
Более подробную информацию об этой команде читайте в статье команда find.
2. locate
Команда locate считается устаревшей и уже была удалена из многих дистрибутивов. Она выполняет поиск не в реальном времени, как find, а по ранее созданной базе файлов, но она делает только поиск файла по имени Linux. Вы вводите слово, которое вас интересует, и утилита выдаёт все известные ей файлы, имя которых содержит такое слово. Возможно использовать регулярные выражения. Например, найдем все файлы, в имени которых содержится passwd:
locate passwd
Обратите внимание, что если файл был добавлен после создания базы, то он найден не будет.
3. grep
Утилита grep позволяет не только фильтровать вывод других команд, но и искать по содержимому файловой системы. Для этого достаточно использовать опцию -r и указать папку, в которой надо искать текст. Например, найдём все файлы в /etc/, которые содержат строчку error_reporting:
sudo grep -r "error_reporting" /etc/
С помощью grep очень удобно искать, где находится нужная конфигурация или же проверять, не содержат ли файлы с кодом чего-нибудь подозрительного. Подробнее про использование grep читайте в статье поиск текста в файлах Linux.
4. whereis
Утилита whereis достаточно простая и решает только одну задачу. Она показывает, где находится исполняемый файл, переданной ей программы. Например, если мы хотим узнать, где лежит grep, достаточно выполнить:
whereis grep
Выводы
В этой статье мы разобрали, как выполнить поиск файла в Linux различными способами, начиная от графического интерфейса и заканчивая терминалом. Как видите, здесь есть множество вариантов, которые позволят вам решить любые задачи по поиску файлов. Возможно, вам также будет интересна статья о том, как узнать pid процесса в Linux, который использует файл, порт или изменяет данные.
(7 оценок, среднее: 4,71 из 5)
Загрузка...
Поправка. Опция -r в grep это рекурсивный поиск. А поиском по содержимому grep занимается и без опций.
which
Я -- программист (-хренов). Пишу проги для микроконтроллеров и для компа. Очень часто после компиляции проекта, состоящего из многих файлов, компилятор выдаёт ошибки. Иногда приходится искать по проекту использование (вызовы) той или иной функции или какие-то другие вещи. Поэтому я интенсивно пользуюсь утилитой grep.
Набрать четыре буквы и к ним еще несколько параметров -- это не такая уж большая работа и не такая катастрофическая потеря времени. По сути (умеючи) всё осуществляется одним взмахом руки над клавиатурой.
Примеры:
grep -n lcd_init *.c # Поиск в исходных файлах проекта, где вызывается инициализация дисплея. Дополнительно к указании имени файла, опция -n также выводит номер строки.
grep -nr post_message *.[ch] # Поиск по всему проекту и его директориям (-r -- флаг рекурсивности просмотра поддиректориев) во всех исходных и хэдерных файлах.
grep -ni led *.c # опция -i заставляет игнорировать регистр буква искомого слова. В результате будут найдены все led, Led, LED, LED_ON, LED_OFF и так далее.
Кроме того, вывод команды grep можно "подкрасить". У меня Debian. А у него в домашнем директории пользователя в файле .bashrc имеется 82-ая строка вот с таким содержанием:
alias grep='grep --color=auto'
Эту строку нужно раскомментировать и перезапустить сессию пользователя.
(Можно очень много интересного написать по работе в Линуксе и можно дать много полезных советов. Линукс огромен, как вселенная! Обилие информации не приводит к увеличению скорости освоения. Вы же не наедаетесь за один раз и на всю неделю. Вы едите каждый день, но по немного. Вы каждую неделю тренируетесь в спортзале или выполняете какие-то силовые нагрузки периодически. Но вы не рвете жо и не губите своё здоровье, как "последний раз". Так и с освоением Линукса -- не нужны не авралы, а нужно методичное освоение. Мудрость гласит -- "Нет! Мы медленно спустимся в долину и возьмём всё стадо." Успехов вам!)
Тогда уж alias добавить в /etc/bash.bashrc, чтоб и для root-а было цветно 😉
А зоодно обратите внимание, сколько раз Вы ткнули в буковку "n", не проще так: alias grep='grep --color=auto -n'
1. А зачем? У root-а совсем иные задачи. Я под root-ом не имею привычки работать над проектами. Root предназначен совсем-совсем для иных целей. Это ж не Винда!
2. Ага. Можно и так. Вроде даже когда-то так тоже делал. А в целом, на брать дополнительно пару символов "-n" абсолютно не напрягает (руки-то не на мышке, а на клаве). Ну и есть волшебная клавиша "Tab", и история команд.
В общем, кому как нравится. Мне нравится так, и кроме того, я уже привык делать именно так. Никого не агитирую делать именно так, как я делаю. Просто предложил свой способ. А каждый сам найдёт для себя единственный удобный для него способ. Ага.
Ну, раз уж про цвет, то ещё чуток offtop-а: gcc у меня тоже цветной 😉 более удобочитаемый вывод 🙂
P.S.: прошу прощения за описочку: зоодно -> заодно 🙂
Ага. Я тоже "подкрасил".
Вот только все возможности в одну статью сваливать я подумал, что это не хорошо. Ну раз уж Вы затронули и этот вопрос, то добавлю.
Строки 86-87 в том же файле:
# colored GCC warnings and errors
export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
Согласен - дело вкуса, но можно и разнообразить: export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01;34:quote=33'
Это потому, Александр Антонович, что вам не хватает внутренней дисциплины и привычки комментировать свой код. Определили функцию в каком-то файле, сделали вызов функции в другом файле, напишите в файле с определением функции соответствующий комментарий с адресом файла, где есть вызов, комментарии для этого и нужны, чтобы потом не делать судорожные поиски и не блукать в трёх соснах под солнцем, но во тьме. Вы даже представить себе не можете, как облегчите свою жизнь в будущем, потратив 3 секунды на полезный комментарий. :))) При этом приставка к слову "программист", которой вы себя обзываете, сама отпадёт... Ни можно так про себя! ;)) Вас молодёжь читает... Пример ещё брать будет.
Ну и для описанного вами случая некоторые программистские IDE имеют соответствующие специализированные инструменты для поиска по проекту. Иногда это бывает удобней чем grep, хотя grep могуч конечно.
ANGRYsearch забыли.
Уважаемый Добряк!
Всё, что Вы говорите -- всё верно!
К сожалению, мои проекты довольно-таки большие. Проект, над которым я сейчас тружусь, насчитывают нескольку десятков файлов, в общей сложности чуть менее 10 тысяч строк. Хозяйство очень большое. Кроме того, это -- разработка. Постоянно что-то меняется, постоянно что-то куда-то переносится.
Ну, например, в схеме используется LCD (OLED) индикатор, микросхема Zig-Bee и вокодер. У всех у них интерфейс SPI. Но у микроконтроллера, который заложен в изделии, только два SPI. Выход простой -- нужно просто объединить два устройства на одном интерфейсе. Я посчитал, что радиоканал из них самый быстрый, и посадил его на один SPI, а LCD и вокодер завёл на другой SPI.
Оказалось, не угадал!
Оказалось, что Zig-Bee может ждать дольше обработки (после того, как микроконтроллер (МК) получит от неё прерывание), чем вокодер. Ну, LCD -- это товарищ вообще не принципиальный, но у него тоже есть неприятное свойство. Он -- графический. А это значит, что вывод информации для подновления изображения на нём потребует значительно больше времени, чем если бы он был символьным. Ну, в общем, вывод небольшого кусочка может занять 1-2 миллисекунды. Если МК начал работать с LCD, то ему не желательно прерваться на обработку вокодера, так как придётся заново выводить этот кусок изображения. С другой стороны, для вокодера 1-2 мс -- это существенное время, которое может нарушить его работу.
В общем, пришлось перемещать LCD от вокодера на радиоканал.
Простой (казалось бы!) вопрос -- в каком файле (модуле) должна осуществляться инициализация интерфейса SPI? Ну тот SPI, который работает на одно устройство, -- там понятно -- там можно проинициализировать его и в самом модуле устройства (в драйвере этого устройства). Например, радиоканал сидел на отдельном SPI, значит, можно SPI можно не выделять в отдельный файл, а объединить его с драйвером радиоканала. А, вот, что делать с вокодером и LCD?
Пришлось создавать три модуля драйверов: один для LCD, другой -- для вокодера, третий -- для их совместно используемого SPI.
Но это ещё ягодки! Потом, когда поднялся вопрос экономии питания, посыпались ягодки. Оказалось, что вокодер даже в режиме сна жрёт довольно-таки много. Пришлось отказаться от этого режима, а тупо отрубать ему питание. Получилось. Но возникла другая проблема.
По логике работы устройства возникают ситуации, когда LCD работает с выключенным вокодером. Но вокодер (собака!), будучи вообще обесточенным, умудряется получить питание и работать через сигнальные цепи, которые являются общими для LCD и вокодера.
Всё бы ничего, но оказалось, что и радиоканал тоже способен нормально запитываться от сигнальных цепей. По идее нужно менять МК на другой, у которого три SPI.
Добряк, я не прошу Вас вникать в описанную проблему. Я это всё не поленился написать для Вас, что бы развеять Ваше чувство, что чужую будку, руками разведу. Пожалуйста, не судите людей по себе. Проекты (программы) бывают чрезвычайно разные. Со стороны всегда кажется -- что там тупить-то!
Ещё бы..! :))))
Могу лишь добавить, что в файлменеджер nemo можно, в качестве расширения, добавить любой поисковик, например, тот же gnome-search-tool
Просто битва Титанов )))) Может Вам, ребятки, телефонами обменяться? )))
А как же Catfish? Тоже неплохая графическая приблуда для поиска.
ripgrep же!