Как найти только исполняемые файлы в определенном каталоге в Linux?
Как я могу найти только исполняемые файлы в определенном каталоге в Linux?
6 ответов
Проверка исполняемых файлов может выполняться с помощью -perm (не рекомендуется) или -executable (рекомендуется, поскольку он учитывает ACL). Чтобы использовать параметр -executable :
, если вы хотите найти только исполняемые файлы, а не каталоги, доступные для поиска, в сочетании с -type f :
Используйте опцию -perm для поиска. Это найдет файлы в текущем каталоге, которые либо исполняются их владельцем, либо членами группы, либо другими:
Я просто нашел еще один вариант, который присутствует, по крайней мере, в GNU find 4.4.0:
Это должно работать еще лучше, потому что ACL также рассматриваются.
Я знаю, что в этом вопросе конкретно упоминается Linux, но поскольку это первый результат в Google, я просто хотел добавить ответ, который я искал (например, если вы — как и я на данный момент, принужден вашим работодателем использовать система не GNU /Linux).
Протестировано на macOS 10.12.5
У меня есть другой подход, в случае, если вы действительно хотите просто сделать что-то с исполняемыми файлами — и не обязательно заставить заставить фильтр фильтровать себя:
Я предпочитаю это, потому что он не полагается на -executable , который является специфичным для платформы; и он не полагается на -perm , который является немного тайным, специфичным для бит-платформы и, как написано выше, требует, чтобы файл исполнялся для всех (а не только для вас).
-type f важен, потому что в каталогах * nix должны быть исполняемыми, чтобы быть обходимыми, и чем больше запросов находится в команде find , тем больше память будет эффективной вашей командой.
Во всяком случае, просто предлагая другой подход, поскольку * nix — это земля в миллиард подходов.
Файл, помеченный как исполняемый файл, не обязательно должен быть исполняемым или загружаемым файлом или объектом.
Вот что я использую:
Как вентилятор одного лайнера .
Использование «xargs» для вывода результата из команды find (с помощью print0 для правильной обработки имен файлов с пробелами). Теперь у нас есть список исполняемых файлов, и мы предоставляем их один за другим в качестве параметра для команды «файл». Затем grep для выражения ASCII для игнорирования двоичных файлов. Пожалуйста, замените -executable в команде find на какой стиль вы предпочитаете (см. Более ранние ответы) или что работает на вашей «ОС NIX
Мне нужно было найти файлы с eval в скриптах, принадлежащих root, поэтому создано следующее, чтобы помочь найти недостатки в личной эскалации, когда пользователь root запускает скрипты с небезопасными параметрами .
Куда устанавливаются программы в Ubuntu
Многих новичков, недавно установивших Linux и только начавших разбираться в устройстве этой замечательной операционной системы, как и меня, в свое время, интересует вопрос: куда же устанавливаются программы в Ubuntu, да и вообще, в любом дистрибутиве Linux. Файловая система Linux очень сильно отличается от Windows и это в первое время сбивает с толку.
Мы привыкли, что все программы и их файлы в Windows находятся в системном каталоге Program Files и System32, или если не в нем, то хотя бы в одном из подкаталогов. Но в Linux все намного сложнее. Здесь файлы программ, как правило, распределены по всей файловой системе. Так куда устанавливаются программы в Linux? Как найти все файлы программы? Как удалять ненужные программы? Все это мы рассмотрим в данной статье.
Куда устанавливаются программы в Ubuntu
Здесь не все так просто. Чтобы ответить на этот вопрос сначала нужно разобраться в особенностях файловой системы Linux и способах установки программ. В корневой файловой системе Linux каждая папка предназначена для хранения определенного типа файлов, эти правила со временем менялись, да и сейчас меняются в зависимости от дистрибутива, но основные папки остаются одни и те же. В папке /bin (Binary — двоичный) — хранятся исполняемые файлы, /lib — подключаемые библиотеки, /usr — ресурсы и данные программ, это могут быть переводы, картинки и т д, в /var — временные данные, логи, кэши, /etc — конфигурационные файлы.
Большинство программ, устанавливаемых с помощью стандартного пакетного менеджера распределяются по файловой системе в эти папки. Вам, наверное, интересно, как система определяет какие файлы куда копировать. Она и не определяет, это задает разработчик во время сборки пакета. Попробуйте открыть deb пакет как архив. Кроме служебных информационных файлов, касающихся установки вы там увидите структуру папок напоминающую корневую ФС Linux, это и определяет какие файлы где будут находиться. В последнее время грань четкого разделения файлов по папкам немного стерлась, появились папки /usr/bin для исполняемых файлов, а кэш некоторые программы вообще хранят в домашней папке пользователя, но традиционные Linux сервисы, такие как Samba, Apache, Ngnix и многие другие четко придерживаются стандартной структуры.
Давайте разберем на примере как распределяется программа в файловой системе. Возьмем, например, тот же сервер apache. Чтобы узнать куда были скопированы файлы программы воспользуемся утилитой dpkg.
www-servers/apache-2.2.31 (/usr/sbin/apache2)
www-servers/apache-2.2.31 (/etc/init.d/apache2)
www-servers/apache-2.2.31 (/etc/logrotate.d/apache2)
www-servers/apache-2.2.31 (/var/cache/apache2)
www-servers/apache-2.2.31 (/usr/lib64/apache2)
www-servers/apache-2.2.31 (/usr/share/apache2)
www-servers/apache-2.2.31 (/etc/apache2)
www-servers/apache-2.2.31 (/usr/include/apache2)
www-servers/apache-2.2.31 (/etc/conf.d/apache2)
www-servers/apache-2.2.31 (/var/log/apache2)
Как видите, все файлы на своих местах.
Но из этого правила есть исключения. Например, многие проприетарные программы и игры устанавливаются полностью в одну папку, так же как и в Windows. Для таких программ есть папка /opt. Посмотрим, например, на Crossover:
sudo dpkg -s crossover-bin
Обычно такой вид установки используют программы, устанавливаемые скриптами в формате .run. Есть еще один вид программ — те, которые собираются из исходников и устанавливаются командой make install. Так программы лучше не устанавливать, потому что файлы, как и в первом случае, распределяются по всей системе, но в этот раз уже без ведома пакетного менеджера. Конечно¸ вы всегда сможете удалить программу командой make uninstall, но нет гарантий что вы не удалите исходники и скрипт очистки не оставит в системе много лишних файлов, которые потом будет трудно найти. Как правильно устанавливать программы из исходников можете посмотреть в статье установка программ из tar.gz
Надеюсь, эта статья помогла вам разобраться с вопросом куда устанавливаются программы в Ubuntu.
Поиск файла в Linux
В операционных системах семейства 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. Она имеет множество возможностей: вы можете искать файлы по имени, дате изменения, создания, использовать регулярные выражения и маски, выполнять определённые действия для найденных файлов, настраивать глубину поиска и многое другое. Например, найдем все файлы, которые начинаются на «Снимок» в папке
/Изображения -iname «Снимок*»
Более подробную информацию об этой команде читайте в статье команда find.
2. locate
Команда locate считается устаревшей и уже была удалена из многих дистрибутивов. Она выполняет поиск не в реальном времени, как find, а по ранее созданной базе файлов, но она делает только поиск файла по имени Linux. Вы вводите слово, которое вас интересует, и утилита выдаёт все известные ей файлы, имя которых содержит такое слово. Возможно использовать регулярные выражения. Например, найдем все файлы, в имени которых содержится passwd:
Обратите внимание, что если файл был добавлен после создания базы, то он найден не будет.
3. grep
Утилита grep позволяет не только фильтровать вывод других команд, но и искать по содержимому файловой системы. Для этого достаточно использовать опцию -r и указать папку, в которой надо искать текст. Например, найдём все файлы в /etc/, которые содержат строчку error_reporting:
sudo grep -r «error_reporting» /etc/
С помощью grep очень удобно искать, где находится нужная конфигурация или же проверять, не содержат ли файлы с кодом чего-нибудь подозрительного. Подробнее про использование grep читайте в статье поиск текста в файлах Linux.
4. whereis
Утилита whereis достаточно простая и решает только одну задачу. Она показывает, где находится исполняемый файл, переданной ей программы. Например, если мы хотим узнать, где лежит grep, достаточно выполнить:
Выводы
В этой статье мы разобрали, как выполнить поиск файла в Linux различными способами, начиная от графического интерфейса и заканчивая терминалом. Как видите, здесь есть множество вариантов, которые позволят вам решить любые задачи по поиску файлов. Возможно, вам также будет интересна статья о том, как узнать pid процесса в Linux, который использует файл, порт или изменяет данные.
Нет похожих записей
Оцените статью:
Об авторе
Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux интересуюсь всем, что связано с информационными технологиями и современной наукой.
16 комментариев
Поправка. Опция -r в grep это рекурсивный поиск. А поиском по содержимому grep занимается и без опций.
Я — программист (-хренов). Пишу проги для микроконтроллеров и для компа. Очень часто после компиляции проекта, состоящего из многих файлов, компилятор выдаёт ошибки. Иногда приходится искать по проекту использование (вызовы) той или иной функции или какие-то другие вещи. Поэтому я интенсивно пользуюсь утилитой 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′
Иногда приходится искать по проекту использование (вызовы) той или иной функции или какие-то другие вещи. Поэтому я интенсивно пользуюсь утилитой grep.
Это потому, Александр Антонович, что вам не хватает внутренней дисциплины и привычки комментировать свой код. Определили функцию в каком-то файле, сделали вызов функции в другом файле, напишите в файле с определением функции соответствующий комментарий с адресом файла, где есть вызов, комментарии для этого и нужны, чтобы потом не делать судорожные поиски и не блукать в трёх соснах под солнцем, но во тьме. Вы даже представить себе не можете, как облегчите свою жизнь в будущем, потратив 3 секунды на полезный комментарий. :))) При этом приставка к слову «программист», которой вы себя обзываете, сама отпадёт. Ни можно так про себя! ;)) Вас молодёжь читает. Пример ещё брать будет.
Ну и для описанного вами случая некоторые программистские IDE имеют соответствующие специализированные инструменты для поиска по проекту. Иногда это бывает удобней чем grep, хотя grep могуч конечно.
Всё, что Вы говорите — всё верно!
К сожалению, мои проекты довольно-таки большие. Проект, над которым я сейчас тружусь, насчитывают нескольку десятков файлов, в общей сложности чуть менее 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.
Добряк, я не прошу Вас вникать в описанную проблему. Я это всё не поленился написать для Вас, что бы развеять Ваше чувство, что чужую будку, руками разведу. Пожалуйста, не судите людей по себе. Проекты (программы) бывают чрезвычайно разные. Со стороны всегда кажется — что там тупить-то!