Как я могу исключить все сообщения об отказе в разрешении из «поиска»?

Question

Как я могу исключить все сообщения об отказе в разрешении из «поиска»?

570

Мне нужно скрыть все отклоненные отклонения от сообщений:

find . > files_and_folders

Я экспериментирую, когда возникает такое сообщение. Мне нужно собрать все папки и файлы, к которым это не возникает.

Можно ли направить уровни разрешений в файл files_and_folders?

Как я могу скрыть ошибки одновременно?

Léo Léopold Hertz 준영 17 апр. 2009, в 21:06

Источник

Теги:

bash

find

error-handling

file-permissions

17 ответов

451

Использование:

find . 2>/dev/null > files_and_folders

Это скрывает не только разрешение, допускающее ошибки, но все сообщения об ошибках.

Если вы действительно хотите сохранить другие возможные ошибки, например, слишком много переходов на символической ссылке, но не на отказ от отказа, тогда вам, вероятно, придется взять летное предположение, что у вас не так много файлов, разрешение отклонено "и попробуйте:

find . 2>&1 | grep -v 'permission denied' > files_and_folders

Если вы строго хотите фильтровать только стандартную ошибку, вы можете использовать более сложную конструкцию:

find . 2>&1 > files_and_folders | grep -v 'permission denied' >&2

Перенаправление ввода-вывода в команде find: 2>&1 > files_and_folders |. Труба перенаправляет стандартный вывод в команду grep и применяется сначала. 2>&1 отправляет стандартную ошибку на то же место, что и стандартный вывод (труба). > files_and_folders отправляет стандартный файл (но не стандартную ошибку) в файл. Конечным результатом является то, что сообщения, записанные в стандартную ошибку, отправляются по каналу, и в файл записывается обычный вывод find. grep фильтрует стандартный вывод (вы можете решить, насколько избирательным вы его хотите, и, возможно, придется менять орфографию в зависимости от языка и O/S), а окончательный >&2 означает, что оставшиеся сообщения об ошибках (записанные на стандартный выход) еще раз перейдите к стандартной ошибке. Окончательное перенаправление можно рассматривать как необязательное на терминале, но было бы очень неплохо использовать его в script, чтобы сообщения об ошибках отображались при стандартной ошибке.

В этой теме бесконечные вариации, в зависимости от того, что вы хотите сделать. Это будет работать над любым вариантом Unix с любой производной оболочки Bourne (Bash, Korn,...) и любой версией find.

Если вы хотите адаптироваться к конкретной версии find, которая у вас есть в вашей системе, могут быть доступны альтернативные варианты. GNU find, в частности, имеет множество параметров, недоступных в других версиях - см. Текущий принятый ответ для одного такого набора параметров.

Jonathan Leffler 17 апр. 2009, в 22:47

9

Если вы похожи на меня, обратите внимание, что нехватка места важна! 2>/dev/null , без пробела!
Nik 25 окт. 2013, в 08:00
19

2> - это единое целое без пробелов; между ним и именем файла может быть пробел. Аналогично с другими перенаправлениями, такими как 2>&1 (который перенаправляет стандартную ошибку в то же место, где происходит стандартный вывод), или 2>&- который закрывает стандартную ошибку, и т. Д. См. Перенаправления для получения дополнительной информации о кровопролитии. (Приведенный выше код является общей оболочкой, подобной POSIX, а не специфичной для bash .)
Jonathan Leffler 25 окт. 2013, в 18:12
3

Я должен был использовать заглавную букву P, потому что это то, что выводит мой терминал: найти. 2> & 1 | grep -v 'В доступе отказано'
David Doria 29 май 2014, в 20:20
1

@DavidDoria вы можете использовать grep -i или (в этом случае) grep -vi чтобы игнорировать регистр.
AndriusZ 12 авг. 2014, в 13:59
4

Как это приемлемое решение? 1) Вы перенаправляете ВСЕ ошибки в dev / null 2) Вы фильтруете явную строку ошибок !! В зависимости от того, насколько они хрупки, и что если ваш файл находится в каталоге с именем «отказано в доступе»? К сожалению!
Gunchars 10 нояб. 2014, в 06:03
1

@Gunchars: вопросы, которые вы поднимаете, отражены в ответе, или явная строка ошибки покрывается спецификацией вопроса. Первая команда отправляет все ошибки в /dev/null ; второй нет. И в ответе упоминается предположение, что у вас нет файлов, называемых permission denied . Итак, мне не ясно, на что вы действительно возражаете.
Jonathan Leffler 10 нояб. 2014, в 06:20
10

Я возражаю против смещения строк ошибок, чтобы изменить вывод программы. Это будет работать большую часть времени, но простое решение не является правильным (найдите с помощью perms ниже). Чтобы дать вам пример почему, это не будет работать в OSX, потому что ошибка «Отказано в доступе». То же самое для любой другой системы, где есть даже незначительные различия в строке ошибки (интернационализация кто-нибудь?)
Gunchars 10 нояб. 2014, в 15:59
1

Чтобы сделать grep-запрос несколько более устойчивым, лучше использовать LANG=C grep поскольку в зависимости от локализации сообщения будут отличаться, и grep не будет соответствовать им. Все еще не так тверд, как ответ пользователя 3701456.
Thomas W 16 фев. 2016, в 09:34
0

@ThomasW: Хороший вопрос, но это команда find (не grep ), которую вы должны ставить с префиксом LANG=C (или, чуть более надежно, LC_ALL=C ).
mklement0 01 нояб. 2016, в 06:18

Показать ещё 7 комментариев

234

Использование:

find . ! -readable -prune -o -print

или в целом

find <paths> ! -readable -prune -o <other conditions like -name> -print

чтобы избежать "Разрешения отказа"
И НЕ подавлять (другие) сообщения об ошибках
И получить статус завершения 0 ( "все файлы обработаны успешно" )

Работает с: find (GNU findutils) 4.4.2. Справочная информация:

Тест -readable соответствует читаемым файлам. Оператор ! возвращает true, когда тест является ложным. И ! -readable соответствует не читаемым каталогам (& файлы).
Действие -prune не входит в каталог.
! -readable -prune можно перевести на: если каталог не читается, не входите в него.
Тест -readable учитывает списки управления доступом и другие артефакты разрешений, которые игнорирует тест -perm.

См. также справочную страницу (1) для более подробной информации.

Michael Brux 11 авг. 2014, в 01:32

1

Как это лучше или хуже, чем ответ Джонатана? У обоих одинаковые выходы?
Léo Léopold Hertz 준영 11 авг. 2014, в 05:31
5

различия уже упоминались. если вы не понимаете, то, возможно, ответы не имеют никакого значения для вас? STDOUT то же самое - STDERR другое (вы получаете другие сообщения об ошибках с этим ответом) - $? отличается (0 «успешно» с этим ответом, когда нет другой ошибки - всегда> 0 «не успешно» при перенаправлении на dev / null) - может быть, кому-то нужен «правильный» $? в сценарии
Michael Brux 11 авг. 2014, в 05:51
4

Я думаю, что это более элегантное решение потока. Мне нравится успешный результат $ ?.
Speredenn 21 нояб. 2014, в 13:43
6

@Masi самый очевидный недостаток - ответ Джонатана (grep -v) исключит имя файла, которое содержит «Отказано в доступе» :)
林果皞 10 апр. 2015, в 20:11
62

Я считаю уместным добавить здесь, что если вам нужно добавить некоторые другие критерии поиска, это должно быть сделано с помощью -o : find . ! -readable -prune -o -name '*.txt'
tempestadept 30 апр. 2015, в 11:08
20

Обратите внимание, что POSIX find не включает в себя -readable как опцию; также не find для BSD и, следовательно, Mac OS X (я не уверен насчет других систем). Таким образом, если у вас есть гарантированный find GNU, это прекрасно работает, но не очевидно, как это адаптировать, если вы не можете гарантировать, что в системе установлен GNU find . (Это будет хорошо работать в Linux; может и не работать в другом месте.)
Jonathan Leffler 27 июнь 2015, в 20:56
6

find . ! -readable -prune -o -name '*.txt' похоже, не работает в Ubuntu 14.04 с использованием find 4.2.2. Это , кажется, Игнорировать регистр -name . По какой-то странной причине у меня есть успех с find . $ ! -readable -prune $ -o -name '*.txt' -print
con-f-use 15 янв. 2016, в 17:10
2

@ con-f-use - у меня была та же проблема, я обнаружил, что мне нужен только -print , а не сложные скобки.
IBam 03 март 2016, в 16:43
0

Есть ли эквивалент игнорировать несуществующие пути? Например, если у меня есть find path1 path2 path3 -type f , я не хочу, чтобы find выдавал ошибку, даже если пути отсутствуют. В противном случае, я должен заранее составить список путей, проверив, какие из них существуют, и отсутствие пути не является для меня ошибочным условием.
haridsv 24 июнь 2016, в 06:58
1

@ con-f-use См. дополнительное объяснение re: скобки и -print здесь: stackoverflow.com/questions/1489277/…
DreadPirateShawn 27 сен. 2016, в 22:16
0

@haridsv: Нет: find неизменно жалуется на несуществующие входные пути. Вы должны будете использовать один из решений , которые фильтр find «s выход Stderr и не отфильтровывать No such file or directory сообщений.
mklement0 30 дек. 2016, в 14:13
0

@MichaelBrux: запоздалый ++; обсуждение ниже моего ответа продолжилось, и, надеюсь, обновленная версия будет более сбалансированной. Читаемый, но не исполняемый каталог. по-прежнему вызывать ошибки с отказом в разрешении для своих дочерних элементов, в конце концов, не является ошибкой: поскольку сам каталог -prune чтения, -prune не -prune , а доступ к дочерним элементам затем завершается неудачно (из-за отсутствия разрешений на исполняемый файл в директории dir). ). Как уже говорилось, это экзотический случай.
mklement0 30 дек. 2016, в 14:38
0

Может ли это быть дополнительно ограничено удалением каталогов, которые не являются исполняемыми в дополнение к нечитаемым?
Andrew McKinlay 16 янв. 2017, в 22:41
1

@AndrewMcKinlay см gnu.org/software/findutils/manual/html_mono/find.html#Mode-Bits GNU находку поддерживает -executable тест
Michael Brux 18 янв. 2017, в 10:27
0

@ con-f-use ваша команда сработала, потому что вы добавили -print до конца. Это действовало на совпадения -name '*.txt'. Когда вы добавляете -print к одному из предложений в -o (логическое ИЛИ), find знает, что вы хотите напечатать только эту часть. В противном случае, если по умолчанию распечатывается все, что он находит. И нечитаемая вещь была «найдена», хотя и не читаема. (... как хорошо описано в ссылке, размещенной DreadPirateShawn, теперь я обращаю внимание)
Dan Pritts 29 март 2017, в 19:05
0

Может быть, вы хотите использовать ! -readable -prune -false для подавления нечитаемых каталогов (и не только предупреждений)
Henning 04 апр. 2017, в 08:49
0

как примечание, кажется, не работает в cygwin / msys env
xenoterracide 16 янв. 2018, в 11:47

Показать ещё 15 комментариев

101

Если вы хотите начать поиск с корневого "/", вы, вероятно, увидите что-то вроде:

find: /./proc/1731/fdinfo: Permission denied
find: /./proc/2032/task/2032/fd: Permission denied

Это из-за разрешения. Чтобы решить эту проблему:

Вы можете использовать команду sudo: sudo find /. -name 'toBeSearched.file'. он запрашивает пароль суперпользователя, когда вы вводите пароль, вы увидите результат, который вы действительно хотите.
Вы можете перенаправить стандартный вывод ошибки (обычно дисплей/экран) на какой-либо файл и не видеть сообщения об ошибках на экране! перенаправить на специальный файл /dev/null:
```
find /. -name 'toBeSearched.file' 2>/dev/null
```
Вы можете перенаправить стандартный вывод ошибки (обычно дисплей/экран) на стандартный вывод (обычно дисплей/экран), затем выполнить команду grep с параметром -v "инвертировать", чтобы не видеть выходные линии который содержит пары слов "Разрешение отказа":
```
find /. -name 'toBeSearched.file' 2>&1 | grep -v 'Permission denied'
```

Fatih Aksu 15 фев. 2012, в 09:05

6

@scottmrogowski за исключением того, что он не отвечает на вопрос ... 1. попросите системного администратора добавить вас в файл sudoers. 2. sudo find...
Stephen 16 июль 2013, в 02:11
1

именно то, что я искал!
DankMasterDan 20 июнь 2018, в 16:40

78

Мне пришлось использовать:

find / -name expect 2>/dev/null

указав имя того, что я хотел найти, а затем сообщив ему перенаправить все ошибки в /dev/null

Предположим, что это место ожидаемой программы, которую я искал.

Jeremy 04 фев. 2012, в 03:56

3

@Masi, команда в ответ не использует expect . Вместо этого expect - это просто имя файла, который попытается найти эта команда.
Dhruv Kapoor 10 фев. 2014, в 08:30
1

Слепое перенаправление всего вывода stderr просто для того, чтобы игнорировать один класс сообщений об ошибках, как правило, плохая идея - вы потеряете все другие произвольные ошибки в процессе.
Josip Rodin 24 сен. 2015, в 12:18

44

Труба stderr до /dev/null с помощью 2 > /dev/null

find . -name '...' 2>/dev/null

Matt 17 апр. 2009, в 22:06

0

Это прекрасно работает даже на Mac OSX. Или даже find . -name '...' -print 2>/dev/null
shadowsheep 19 фев. 2018, в 11:32

29

Вы также можете использовать предикаты -perm и -prune, чтобы избежать спускаться в нечитаемые каталоги (см. также Как удалить заявления о выдаче разрешений с разрешения из программы поиска? - Unix и Linux Stack Exchange):

find . -type d ! -perm -g+r,u+r,o+r -prune -o -print > files_and_folders

sdaau 23 март 2014, в 16:08

3

-perm -g+r,u+r,o+r просто сопоставляет файлы, для которых установлены разрешения r (чтение) для всех 3 участников безопасности файла , что не имеет прямого отношения к тому, может ли текущий пользователь прочитать этот файл или не. Он может пропустить файлы, которые текущий пользователь может прочитать, и сопоставить файлы, которые он не может.
mklement0 24 окт. 2016, в 03:33
0

Я думаю, что find . -type d ! $ -perm -u+r -o -perm -g+r -o -perm -o+r $ -prune -o -print было бы хорошим решением.
Mattia72 29 нояб. 2016, в 09:16
1

@ Mattia72: Нет, принципиально невозможно полностью эмулировать -readable с -perm - посмотрите мой предыдущий комментарий и рассмотрите этот пример: echo 'hi' > file; sudo chown nobody:nobody file; sudo chmod or file; find file -perm -u=r печатает file , потому что установлен его пользовательский бит чтения, но он относится к пользователю nobody , а не к текущему пользователю. Текущий пользователь не может прочитать этот файл; попробуйте cat file . Смотрите также: это мой ответ .
mklement0 16 янв. 2017, в 20:02

Показать ещё 1 комментарий

21

Переназначить стандартную ошибку. Например, если вы используете bash на машине unix, вы можете перенаправить стандартную ошибку на /dev/null, как это:

find . 2>/dev/null >files_and_folders

Jason Coco 17 апр. 2009, в 22:47

17

В то время как вышеприведенные подходы не затрагивают случай для Mac OS X, потому что Mac Os X не поддерживает переключатель -readable, так вы можете избежать ошибок "Разрешения на отказ" в вашем выпуске. Это может помочь кому-то.

find / -type f -name "your_pattern" 2>/dev/null.

Если вы используете некоторую другую команду с find, например, чтобы найти размер файлов определенного шаблона в каталоге 2>/dev/null, все равно будет работать, как показано ниже.

find . -type f -name "your_pattern" -exec du -ch {} + 2>/dev/null | grep total$.

Это вернет общий размер файлов данного шаблона. Обратите внимание на 2>/dev/null в конце команды find.

Bunti 01 фев. 2016, в 23:27

0

Хорошая привязка к OS X! Ответ Джонатана объясняет часть 2>/dev/null . Можете ли вы объяснить часть -exec du -ch {} + 2>/dev/null | grep total$ .
Léo Léopold Hertz 준영 02 фев. 2016, в 09:58
1

@Masi Вы можете использовать любую команду с опцией -exec чтобы выполнить дальнейшие действия с файлами или каталогами, найденными командой find . du -ch file_pattern вычисляет размер каждого файла, совпадающего с file_pattern и последняя строка этого вывода представляет собой общую сумму всех файлов, которые соответствуют file_pattern . Смотрите man-страницу для du . grep total просто фильтрует строку, которая извлекает общий итог (последняя строка).
Bunti 02 фев. 2016, в 22:23

12

Эти ошибки выводятся на стандартный вывод ошибки (fd 2). Чтобы отфильтровать их, просто переадресуйте все ошибки в /dev/null:

find . 2>/dev/null > some_file

или сначала присоедините stderr и stdout, а затем вычеркните эти конкретные ошибки:

find . 2>&1 | grep -v 'Permission denied' > some_file

viraptor 17 апр. 2009, в 22:44

7

Простой ответ:

find . > files_and_folders 2>&-

2>&- закрывает (-) стандартный дескриптор файла ошибки (2), поэтому все сообщения об ошибках отключены.

Код выхода по-прежнему будет 1, если в противном случае будут напечатаны ошибки <<25 >

Надежный ответ для GNU `find`:

find . -type d \! $ -readable -executable $ -prune -print -o -print > files_and_folders

Передайте дополнительные опции find, которые -prune (не спускайтесь), но -print любой каталог (-type d), который не (\!) имеют -readable и -executable или (-o) -print любой другой файл.

-readable и -executable параметры Расширения GNU, а не часть стандарт POSIX
Может по-прежнему возвращать 'Permission denied' в ненормальные/поврежденные файлы (например, см. отчет об ошибках, влияющий на файловые системы, монтируемые на контейнерах, с помощью lxcfs < v2.0.5)

Надежный ответ, который работает с любым совместимым с POSIX `find` (GNU, OSX/BSD и т.д.)

{ LC_ALL=C find . 3>&2 2>&1 1>&3 > files_and_folders | grep -v 'Permission denied'; [ $? = 1 ]; } 3>&2 2>&1

Используйте конвейер, чтобы передать стандартный поток ошибок grep, удалив все строки, содержащие строку 'Permission denied'.

LC_ALL=C устанавливает локаль POSIX, используя переменную среды , 3>&2 2>&1 1>&3 и 3>&2 2>&1 дублировать файловые дескрипторы, чтобы передать поток стандартной ошибки в grep, а [ $? = 1 ] использует [], чтобы инвертировать код ошибки, возвращенный grep, чтобы приблизить исходное поведение find.

Также будет фильтровать любые ошибки 'Permission denied' из-за перенаправления вывода (например, если сам файл files_and_folders не доступен для записи)

wjordan 25 дек. 2016, в 05:33

0

Как вы относитесь к предложению JordiFerran? - Можете ли вы сравнить свой ответ с этим?
Léo Léopold Hertz 준영 25 дек. 2016, в 09:13
2

Сценарий оболочки этого ответа, как указано, не является универсальным (только перечисляет каталоги, соответствующие $ {m_find_name}) и содержит несколько опций, не относящихся к вопросу (nice, / home *, -maxdepth 5, -follow). Этот ответ более конкретно решает проблему «фильтрации читаемых, но не исполняемых каталогов», оставаясь при этом универсальным.
wjordan 25 дек. 2016, в 13:23
1

@wjordan: Спасибо. Я удалил свои комментарии, но один пункт все еще применим: -perm основе -perm не стоит представлять, потому что оно более фундаментально, чем предполагает цитата, делает нечто иное, чем предполагалось: это чисто файлово-ориентированный тест, относящийся к Владелец и группа файла , ни одна из которых не имеет каких-либо гарантированных отношений с пользователем, вызывающим команду (см. мой ответ . Похоже, что ваше пересмотренное решение GNU теперь не распознает ошибки, в которых отказано в разрешении, возникающие из файлов .
mklement0 25 дек. 2016, в 20:43
0

Я не распознаю синтаксис, который вы используете (ни как GNU, ни как BSD), но позвольте мне проиллюстрировать мою точку зрения на отдельном примере: echo 'hi' > file; sudo chown nobody:nobody file; sudo chmod or file; find file -perm -u=r печатает file , потому что установлен его пользовательский бит чтения, но он относится к пользователю nobody , а не к текущему пользователю. Текущий пользователь не может прочитать этот файл; попробуйте cat file .
mklement0 25 дек. 2016, в 23:41
1

@ mklement0 спасибо за обсуждение, мне удалось создать поведение, описанное вами в другом тесте (не знаю, что я сделал неправильно в первый раз), похоже, что -perm не работает для определения текущих разрешений пользователя. Убрал эту альтернативу из этого ответа.
wjordan 26 дек. 2016, в 06:09

Показать ещё 3 комментария

3

использование

sudo find / -name file.txt

Это глупо (потому что вы поднимаете поиск) и небезопасно, но гораздо короче, чтобы писать.

mist 16 дек. 2014, в 11:52

0

Вы ищете здесь всю файловую систему, так что вы подразумеваете под этим «повысить поиск». Почему вы называете это небезопасным? Потому что он ищет всю файловую систему?
Léo Léopold Hertz 준영 16 дек. 2014, в 12:06
2

Потому что sudo запускает команду find с правами root, что в принципе является плохой идеей. Принципы сегрегации и наименьших привилегий нарушаются.
mist 16 дек. 2014, в 12:22
2

«Возвышение» здесь имеет привилегии, root, с sudo . Вы рискуете испортить всю систему из-за ошибки в find или злонамеренной версии, или из-за неправильного вызова, который что-то неожиданно пишет, чего не может произойти, если вы запустите это с обычными привилегиями.
tripleee 07 дек. 2015, в 05:34

Показать ещё 1 комментарий

3

Чтобы избежать только запрещенных разрешений, скажите find, чтобы игнорировать нечитаемые файлы, обрезая их из поиска. Добавьте выражение как OR к вашей находке, например

find / \! -readable -prune -o -name '*.jbd' -ls

В основном это говорит (сопоставьте нечитаемый файл и обрезайте его из списка) ИЛИ (сопоставьте имя, например *.jbd, и покажите его [с помощью ls]). (Помните, что по умолчанию выражения AND'd вместе, если вы не используете -or.) Вам нужно использовать -ls во втором выражении, иначе find может добавить действие по умолчанию, чтобы показать либо совпадение, которое также покажет вам все нечитаемые файлы.

Но если вы ищете реальные файлы в своей системе, обычно нет причин для поиска в /dev, у которого много файлов, поэтому вы должны добавить выражение, исключающее этот каталог, например:

find / -mount \! -readable -prune  -o  -path /dev -prune  -o  -name '*.jbd' -ls

Итак, (совпадающий с нечитаемым файлом и черновик из списка) ИЛИ (путь соответствия /dev и обрезка из списка) ИЛИ (файл соответствия, например *.jbd, и его отображение).

simpleuser 16 сен. 2014, в 01:58

2

не может заставить его работать на OS X
mist 18 дек. 2014, в 08:40
4

найти: -читаемое: неизвестный основной или оператор на MAC OS
Gank 28 дек. 2014, в 02:13

2

Вы можете использовать grep -v invert-match

-v, --invert-match        select non-matching lines

вот так:

find . > files_and_folders
cat files_and_folders | grep -v "permission denied" > files_and_folders

Должно к магии

Leonardo Hermoso 27 дек. 2016, в 05:29

1

Ни один из вышеперечисленных ответов не работал у меня. Все, что я нахожу в Интернете, фокусируется на: спрятать ошибки. Ни один из них не обрабатывает обратный код процесса/код выхода. Я использую команду find в сценариях bash, чтобы найти некоторые каталоги, а затем проверить их содержимое. Я оцениваю успех поиска команды с помощью кода exit: нулевое значение работает, в противном случае терпит неудачу.

Ответ представленный выше Майкл Брюкс работает иногда. Но у меня есть один сценарий, в котором он терпит неудачу! Я обнаружил проблему и исправил ее сам. Мне нужно обрезать файлы, когда:

it is a directory AND has no read access AND/OR has no execute access

См. ключевую проблему: AND/OR. Одна хорошая рекомендуемая последовательность условий, которую я прочитал:

-type d ! -readable ! -executable -prune

Это не работает всегда. Это означает, что черновик вызывается, когда совпадение:

it is directory AND no read access AND no execute access

Эта последовательность выражений терпит неудачу, если предоставляется доступ для чтения, но не имеет доступа к выполнению.

После некоторого тестирования я понял об этом и изменил решение моей оболочки script на:

nice find/home */-maxdepth 5 -follow\
$-type d -a !\(-readable -a -executable $ \) -prune\
-o\
$-type d -a -readable -a -executable -a -name" ${m_find_name} "$ -print

Ключ здесь состоит в том, чтобы поместить "неправда" для комбинированного выражения:

has read access AND has execute access

В противном случае он не имеет полного доступа, что означает: обрезать его. Это оказалось для меня одним сценарием, который ранее не предлагал решения.

Ниже приводятся технические детали для вопросов в разделе комментариев. Приносим извинения, если детали чрезмерны.

¿Зачем использовать команду nice? Я получил идею здесь. Первоначально я думал, что было бы неплохо уменьшить приоритет процесса при просмотре всей файловой системы. Я понял, что это не имеет для меня никакого смысла, так как мой script ограничен несколькими каталогами. Я уменьшил -maxdepth до 3.
¿Зачем искать в /home */? Это не относится к этой теме. Я устанавливаю все приложения вручную, используя исходный код для компиляции с не привилегированными пользователями (не root). Они установлены внутри "/home". Я могу иметь несколько двоичных файлов и версий, живущих вместе. Мне нужно найти все каталоги, проверить и выполнить резервное копирование в режиме "ведущий-ведомый". У меня может быть несколько "/home" (несколько дисков, запущенных на выделенном сервере).
¿Зачем использовать -follow? Пользователи могут создавать символические ссылки на каталоги. Это зависит от полезности, мне нужно вести запись об обнаруженных абсолютных путях.

Jordi Ferran 22 дек. 2016, в 12:27

0

Спасибо за ваш ответ и приятные наблюдения! Я открыл щедрость здесь, чтобы лучше просмотреть ваш ответ. Я думаю, что это хорошая находка, не препятствующая доступу для чтения и выполнения. - - Не могли бы вы объяснить, почему вы используете nice и find $HOME -maxdepth 5 -follow ... ?
Léo Léopold Hertz 준영 22 дек. 2016, в 11:21
2

Сценарий оболочки, как указано, не является универсальным (содержит только каталоги, соответствующие ${m_find_name} ) и содержит несколько параметров, не относящихся к данному вопросу ( nice , /home* , -maxdepth 5 , -follow ). Я добавил ответ, который более конкретно решает проблему «фильтрации читаемых, но не исполняемых каталогов», оставаясь при этом универсальным.
wjordan 25 дек. 2016, в 04:33

0

- = Для MacOS = -

Создайте новую команду, используя псевдоним: просто добавьте строку ~/.bash_profile:

alias search='find / -name $file 2>/dev/null'

и в новом окне терминала вы можете вызвать его:

$ file=<filename or mask>; search

например:

$file = etc; поиск

uptech 09 авг. 2017, в 23:16

-1

Вы также можете легко найти результаты поиска в файле.

найти. -name 'NameOfSearchedFile' → results.txt

korodani 17 май 2017, в 13:00

2

Каким образом это отвечает на первоначальный вопрос?
DotBert 17 май 2017, в 12:59
0

Это обходной путь.
korodani 17 май 2017, в 13:19
1

Это не обходной путь, потому что в файле будут также сообщения об ошибках, я думаю :), и он уже делает это .. Возможно, комбинация find . <condition> 2>/dev/null >> results.txt должен работать
xxxvodnikxxx 12 дек. 2017, в 10:20

Показать ещё 1 комментарий

Ещё вопросы

Если вы похожи на меня, обратите внимание, что нехватка места важна! 2>/dev/null , без пробела!
2> - это единое целое без пробелов; между ним и именем файла может быть пробел. Аналогично с другими перенаправлениями, такими как 2>&1 (который перенаправляет стандартную ошибку в то же место, где происходит стандартный вывод), или 2>&- который закрывает стандартную ошибку, и т. Д. См. Перенаправления для получения дополнительной информации о кровопролитии. (Приведенный выше код является общей оболочкой, подобной POSIX, а не специфичной для bash .)
Я должен был использовать заглавную букву P, потому что это то, что выводит мой терминал: найти. 2> & 1 | grep -v 'В доступе отказано'
@DavidDoria вы можете использовать grep -i или (в этом случае) grep -vi чтобы игнорировать регистр.
Как это приемлемое решение? 1) Вы перенаправляете ВСЕ ошибки в dev / null 2) Вы фильтруете явную строку ошибок !! В зависимости от того, насколько они хрупки, и что если ваш файл находится в каталоге с именем «отказано в доступе»? К сожалению!
@Gunchars: вопросы, которые вы поднимаете, отражены в ответе, или явная строка ошибки покрывается спецификацией вопроса. Первая команда отправляет все ошибки в /dev/null ; второй нет. И в ответе упоминается предположение, что у вас нет файлов, называемых permission denied . Итак, мне не ясно, на что вы действительно возражаете.
Я возражаю против смещения строк ошибок, чтобы изменить вывод программы. Это будет работать большую часть времени, но простое решение не является правильным (найдите с помощью perms ниже). Чтобы дать вам пример почему, это не будет работать в OSX, потому что ошибка «Отказано в доступе». То же самое для любой другой системы, где есть даже незначительные различия в строке ошибки (интернационализация кто-нибудь?)
Чтобы сделать grep-запрос несколько более устойчивым, лучше использовать LANG=C grep поскольку в зависимости от локализации сообщения будут отличаться, и grep не будет соответствовать им. Все еще не так тверд, как ответ пользователя 3701456.
@ThomasW: Хороший вопрос, но это команда find (не grep ), которую вы должны ставить с префиксом LANG=C (или, чуть более надежно, LC_ALL=C ).
Как это лучше или хуже, чем ответ Джонатана? У обоих одинаковые выходы?
различия уже упоминались. если вы не понимаете, то, возможно, ответы не имеют никакого значения для вас? STDOUT то же самое - STDERR другое (вы получаете другие сообщения об ошибках с этим ответом) - $? отличается (0 «успешно» с этим ответом, когда нет другой ошибки - всегда> 0 «не успешно» при перенаправлении на dev / null) - может быть, кому-то нужен «правильный» $? в сценарии
Я думаю, что это более элегантное решение потока. Мне нравится успешный результат $ ?.
@Masi самый очевидный недостаток - ответ Джонатана (grep -v) исключит имя файла, которое содержит «Отказано в доступе» :)
Я считаю уместным добавить здесь, что если вам нужно добавить некоторые другие критерии поиска, это должно быть сделано с помощью -o : find . ! -readable -prune -o -name '*.txt'
Обратите внимание, что POSIX find не включает в себя -readable как опцию; также не find для BSD и, следовательно, Mac OS X (я не уверен насчет других систем). Таким образом, если у вас есть гарантированный find GNU, это прекрасно работает, но не очевидно, как это адаптировать, если вы не можете гарантировать, что в системе установлен GNU find . (Это будет хорошо работать в Linux; может и не работать в другом месте.)
find . ! -readable -prune -o -name '*.txt' похоже, не работает в Ubuntu 14.04 с использованием find 4.2.2. Это , кажется, Игнорировать регистр -name . По какой-то странной причине у меня есть успех с find . $ ! -readable -prune $ -o -name '*.txt' -print
@ con-f-use - у меня была та же проблема, я обнаружил, что мне нужен только -print , а не сложные скобки.
Есть ли эквивалент игнорировать несуществующие пути? Например, если у меня есть find path1 path2 path3 -type f , я не хочу, чтобы find выдавал ошибку, даже если пути отсутствуют. В противном случае, я должен заранее составить список путей, проверив, какие из них существуют, и отсутствие пути не является для меня ошибочным условием.
@ con-f-use См. дополнительное объяснение re: скобки и -print здесь: stackoverflow.com/questions/1489277/…
@haridsv: Нет: find неизменно жалуется на несуществующие входные пути. Вы должны будете использовать один из решений , которые фильтр find «s выход Stderr и не отфильтровывать No such file or directory сообщений.
@MichaelBrux: запоздалый ++; обсуждение ниже моего ответа продолжилось, и, надеюсь, обновленная версия будет более сбалансированной. Читаемый, но не исполняемый каталог. по-прежнему вызывать ошибки с отказом в разрешении для своих дочерних элементов, в конце концов, не является ошибкой: поскольку сам каталог -prune чтения, -prune не -prune , а доступ к дочерним элементам затем завершается неудачно (из-за отсутствия разрешений на исполняемый файл в директории dir). ). Как уже говорилось, это экзотический случай.
Может ли это быть дополнительно ограничено удалением каталогов, которые не являются исполняемыми в дополнение к нечитаемым?
@AndrewMcKinlay см gnu.org/software/findutils/manual/html_mono/find.html#Mode-Bits GNU находку поддерживает -executable тест
@ con-f-use ваша команда сработала, потому что вы добавили -print до конца. Это действовало на совпадения -name '*.txt'. Когда вы добавляете -print к одному из предложений в -o (логическое ИЛИ), find знает, что вы хотите напечатать только эту часть. В противном случае, если по умолчанию распечатывается все, что он находит. И нечитаемая вещь была «найдена», хотя и не читаема. (... как хорошо описано в ссылке, размещенной DreadPirateShawn, теперь я обращаю внимание)
Может быть, вы хотите использовать ! -readable -prune -false для подавления нечитаемых каталогов (и не только предупреждений)
как примечание, кажется, не работает в cygwin / msys env
@scottmrogowski за исключением того, что он не отвечает на вопрос ... 1. попросите системного администратора добавить вас в файл sudoers. 2. sudo find...
@Masi, команда в ответ не использует expect . Вместо этого expect - это просто имя файла, который попытается найти эта команда.
Слепое перенаправление всего вывода stderr просто для того, чтобы игнорировать один класс сообщений об ошибках, как правило, плохая идея - вы потеряете все другие произвольные ошибки в процессе.
Это прекрасно работает даже на Mac OSX. Или даже find . -name '...' -print 2>/dev/null
-perm -g+r,u+r,o+r просто сопоставляет файлы, для которых установлены разрешения r (чтение) для всех 3 участников безопасности файла , что не имеет прямого отношения к тому, может ли текущий пользователь прочитать этот файл или не. Он может пропустить файлы, которые текущий пользователь может прочитать, и сопоставить файлы, которые он не может.
Я думаю, что find . -type d ! $ -perm -u+r -o -perm -g+r -o -perm -o+r $ -prune -o -print было бы хорошим решением.
@ Mattia72: Нет, принципиально невозможно полностью эмулировать -readable с -perm - посмотрите мой предыдущий комментарий и рассмотрите этот пример: echo 'hi' > file; sudo chown nobody:nobody file; sudo chmod or file; find file -perm -u=r печатает file , потому что установлен его пользовательский бит чтения, но он относится к пользователю nobody , а не к текущему пользователю. Текущий пользователь не может прочитать этот файл; попробуйте cat file . Смотрите также: это мой ответ .
Хорошая привязка к OS X! Ответ Джонатана объясняет часть 2>/dev/null . Можете ли вы объяснить часть -exec du -ch {} + 2>/dev/null | grep total$ .
@Masi Вы можете использовать любую команду с опцией -exec чтобы выполнить дальнейшие действия с файлами или каталогами, найденными командой find . du -ch file_pattern вычисляет размер каждого файла, совпадающего с file_pattern и последняя строка этого вывода представляет собой общую сумму всех файлов, которые соответствуют file_pattern . Смотрите man-страницу для du . grep total просто фильтрует строку, которая извлекает общий итог (последняя строка).
Как вы относитесь к предложению JordiFerran? - Можете ли вы сравнить свой ответ с этим?
Сценарий оболочки этого ответа, как указано, не является универсальным (только перечисляет каталоги, соответствующие $ {m_find_name}) и содержит несколько опций, не относящихся к вопросу (nice, / home *, -maxdepth 5, -follow). Этот ответ более конкретно решает проблему «фильтрации читаемых, но не исполняемых каталогов», оставаясь при этом универсальным.
@wjordan: Спасибо. Я удалил свои комментарии, но один пункт все еще применим: -perm основе -perm не стоит представлять, потому что оно более фундаментально, чем предполагает цитата, делает нечто иное, чем предполагалось: это чисто файлово-ориентированный тест, относящийся к Владелец и группа файла , ни одна из которых не имеет каких-либо гарантированных отношений с пользователем, вызывающим команду (см. мой ответ . Похоже, что ваше пересмотренное решение GNU теперь не распознает ошибки, в которых отказано в разрешении, возникающие из файлов .
Я не распознаю синтаксис, который вы используете (ни как GNU, ни как BSD), но позвольте мне проиллюстрировать мою точку зрения на отдельном примере: echo 'hi' > file; sudo chown nobody:nobody file; sudo chmod or file; find file -perm -u=r печатает file , потому что установлен его пользовательский бит чтения, но он относится к пользователю nobody , а не к текущему пользователю. Текущий пользователь не может прочитать этот файл; попробуйте cat file .
@ mklement0 спасибо за обсуждение, мне удалось создать поведение, описанное вами в другом тесте (не знаю, что я сделал неправильно в первый раз), похоже, что -perm не работает для определения текущих разрешений пользователя. Убрал эту альтернативу из этого ответа.
Вы ищете здесь всю файловую систему, так что вы подразумеваете под этим «повысить поиск». Почему вы называете это небезопасным? Потому что он ищет всю файловую систему?
Потому что sudo запускает команду find с правами root, что в принципе является плохой идеей. Принципы сегрегации и наименьших привилегий нарушаются.
«Возвышение» здесь имеет привилегии, root, с sudo . Вы рискуете испортить всю систему из-за ошибки в find или злонамеренной версии, или из-за неправильного вызова, который что-то неожиданно пишет, чего не может произойти, если вы запустите это с обычными привилегиями.
не может заставить его работать на OS X
найти: -читаемое: неизвестный основной или оператор на MAC OS
Спасибо за ваш ответ и приятные наблюдения! Я открыл щедрость здесь, чтобы лучше просмотреть ваш ответ. Я думаю, что это хорошая находка, не препятствующая доступу для чтения и выполнения. - - Не могли бы вы объяснить, почему вы используете nice и find $HOME -maxdepth 5 -follow ... ?
Сценарий оболочки, как указано, не является универсальным (содержит только каталоги, соответствующие ${m_find_name} ) и содержит несколько параметров, не относящихся к данному вопросу ( nice , /home* , -maxdepth 5 , -follow ). Я добавил ответ, который более конкретно решает проблему «фильтрации читаемых, но не исполняемых каталогов», оставаясь при этом универсальным.
Каким образом это отвечает на первоначальный вопрос?
Это не обходной путь, потому что в файле будут также сообщения об ошибках, я думаю :), и он уже делает это .. Возможно, комбинация find . <condition> 2>/dev/null >> results.txt должен работать

mklement0 · Accepted Answer · 2016-10-31T04-41-00.000Z

^{Примечание:

* Этот ответ, вероятно, идет глубже, чем ордера на использование, и find 2>/dev/null может быть достаточно хорошим во многих ситуациях. Он может по-прежнему представлять интерес для кросс-платформенной перспективы и для обсуждения некоторых передовых методов оболочки в интересах нахождения решения, которое является настолько устойчивым, насколько это возможно, даже несмотря на то, что защищенные от него случаи могут быть в значительной степени гипотетическими.
* Если ваша система настроена на отображение локализованных сообщений об ошибках, префикс вызовов find ниже LC_ALL=C (LC_ALL=C find ...), чтобы сообщить о сообщениях на английском языке, чтобы grep -v 'Permission denied' работал как предназначена. Неизменно, однако, любые сообщения об ошибках, которые будут отображаться, будут также на английском языке.}

Если ваша оболочка bash или zsh, там решение, которое является надежным, будучи достаточно простым, используя только POSIX-совместимый find функции; в то время как bash сам по себе не является частью POSIX, большинство современных платформ Unix поставляются с ним, что делает это решение широко переносимым:

find . > files_and_folders 2> >(grep -v 'Permission denied' >&2)

Примечание. Небольшая вероятность того, что некоторые из результатов grep могут появиться после завершения find, потому что общая команда не ждет завершения команды внутри >(...). В bash вы можете предотвратить это, добавив | cat к команде.

>(...) является (редко используемым) выходом замещение процесса, которое позволяет перенаправить вывод (в этом случае вывод stderr (2>) в stdin команды внутри >(...).
В дополнение к bash и zsh, ksh также поддерживает их в принципе, но попытка объединить их с перенаправлением из stderr, как это делается здесь (2> >(...)), кажется молча игнорируемой (в ksh 93u+).
- grep -v 'Permission denied' отфильтровывает (-v) все строки (из потока stderr команды find), которые содержат фразу Permission denied, и выводит оставшиеся строки на stderr (>&2).

Этот подход:

надежный: grep применяется только к сообщениям об ошибках (а не к комбинациям путей к файлам и сообщениям об ошибках, что может привести к ложным срабатываниям) и сообщения об ошибках, отличные от разрешения -пределенные передаются через stderr.
свободный от побочного эффекта: find код выхода сохраняется: невозможность доступа хотя бы к одному из найденных элементов файловой системы в код выхода 1 (хотя это выиграло ' t сообщите, произошли ли ошибки, отличные от разрешенных прав).

POSIX-совместимые решения:

Полностью совместимые с POSIX решения либо имеют ограничения, либо требуют дополнительной работы.

Если вывод find должен быть сохранен в файле в любом случае (или вообще подавлен), тогда решение на основе трубопровода из Джонатан Леффлер ответит является простым, надежным и совместимым с POSIX:

find . 2>&1 >files_and_folders | grep -v 'Permission denied' >&2

Обратите внимание, что порядок перенаправления имеет значение: 2>&1 должен быть первым.

Захват вывода stdout в фронте файла позволяет 2>&1 отправлять только сообщения об ошибках по конвейеру, которые grep может затем недвусмысленно работать.

Единственным недостатком является то, что общий код выхода будет <<2 → grep, а не find ', что в данном случае означает: если ошибок нет или только разрешение -пределенные ошибки, код выхода будет 1 (отказ сигнализации), в противном случае (ошибки, отличные от разрешенных) 0 - это противоположность намерения.
Тем не менее, find код выхода редко используется в любом случае, поскольку он часто передает небольшую информацию за пределы фундаментального отказа, например, прохождение несуществующего пути.
Однако конкретный случай, когда даже некоторые из входных путей недоступны из-за отсутствия разрешений, отражается в коде выхода find (как в GNU, так и в BSD find): если ошибка с отказами разрешена для любого из файлы, код выхода установлен на 1.

Следующий вариант описывает, что:

find . 2>&1 >files_and_folders | { grep -v 'Permission denied' >&2; [ $? -eq 1 ]; }

Теперь код выхода указывает, произошли ли какие-либо ошибки, кроме Permission denied: 1, если это так, 0 в противном случае.
Другими словами: код выхода теперь отражает истинное намерение команды: сообщается об успехе (0), если не произошло никаких ошибок или только ошибок, связанных с разрешением.
Это, возможно, даже лучше, чем просто прохождение кода find exit, как в решении вверху.

gniourf_gniourfв комментариях предлагается (по-прежнему совместимый с POSIX) обобщение этого решения с использованием сложных перенаправлений, который работает даже с поведением по умолчанию для печати путей к файлу в stdout:

{ find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1

Вкратце: Пользовательский дескриптор файла 3 используется для временной замены stdout (1) и stderr (2), так что сообщения об ошибках могут быть отправлены по протоколу grep через stdout.

Без этих перенаправлений, как данные (пути к файлам), так и сообщения об ошибках будут переданы по протоколу grep через stdout, а grep не сможет отличить сообщение об ошибке Permission denied и (гипотетический) файл, имя содержит фразу Permission denied.

Как и в первом решении, сообщенный код выхода будет grep 's, а не find', но можно применить те же исправления, что и выше.

Заметки по существующим ответам:

Есть несколько моментов, чтобы отметить ответ Майкла Брукса, find . ! -readable -prune -o -print:
- Для этого требуется GNU find; в частности, он не будет работать на macOS. Конечно, если вам нужна только команда для работы с GNU find, это не будет проблемой для вас.
- Некоторые ошибки Permission denied могут по-прежнему отображаться: find ! -readable -prune сообщает о таких ошибках для дочерних элементов каталогов, для которых у текущего пользователя есть разрешение r, но отсутствует x (исполняемое) разрешение. Причина в том, что, поскольку сам каталог доступен для чтения, -prune не выполняется, и попытка спускаться в этот каталог затем вызывает сообщения об ошибках. Тем не менее, типичный случай заключается в отсутствии разрешения r.
- Примечание. Следующим моментом является вопрос о философии и/или конкретном случае использования, и вы можете решить, что это не относится к вам, и что команда соответствует вашим потребностям, особенно если просто печатать пути все вы делаете:
  - Если вы концептуализируете фильтрацию сообщений об ошибках, разрешенных с разрешения, отдельную задачу, которую вы хотите применить к любой команде find, тогда противоположный подход к профилактическому предотвращению ошибок, связанных с разрешением, требует введения "шума" в команда find, которая также вводит сложности и логические ловушки.
  - Например, самый проголосовавший комментарий Майкла (на момент написания этой статьи) пытается показать, как продлить команду, включив фильтр -name следующим образом:
    find . ! -readable -prune -o -name '*.txt'
    Это, однако, не работает так, как предполагалось, потому что требуется завершающее действие -print (объяснение можно найти в этом ответе). Такие тонкости могут вводить ошибки.
Первое решение в Джонатан Леффлер отвечает, find . 2>/dev/null > files_and_folders, как он сам утверждает, слепо молчает все сообщения об ошибках ( и обходной путь является громоздким и не полностью надежным, как он объясняет). Прагматично говоря, однако, это простейшее решение, так как вы можете быть довольным предположить, что любые и все ошибки будут связаны с разрешением.
answer answer, sudo find . > files_and_folders, является кратким и прагматичным, но не рекомендуется ни для чего другого, кроме простого для печати имен файлов, по соображениям безопасности: поскольку вы работаете как пользователь root, "вы рискуете, что вся ваша система запуталась в ошибке поиска или вредоносной версии или неправильном вызове, который пишет что-то неожиданное, чего не может быть, если вы запускал это с обычными привилегиями" (из комментария к туманному ответу tripleee).
Второе решение в ответе viraptor, find . 2>&1 | grep -v 'Permission denied' > some_file запускает риск ложных срабатываний (из-за отправки комбинации stdout и stderr по конвейеру), и, возможно, вместо того, чтобы сообщать о недопустимых ошибках через stderr, захватывает их вместе с выходными путями в выходном файле.

Просто быстрый вопрос: почему вы используете подстановку процесса, а не просто канал: find . 2>&1 > files_and_folders | grep -v 'Permission denied' >&2 ?
@ LéoLéopoldHertz 준영: Если вы не хотите выводить во внешний файл, просто сделайте больше сантехники: { find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1
@ LéoLéopoldHertz 준영: Просто, что это POSIX-совместимый. Замены процесса >(...) относятся к Bash.
Я не уверен, что сохранение кода выхода find должно быть подчеркнуто и объявлено: код выхода find как известно, бесполезен. Здесь очень вероятно, что он будет ненулевым (и бесполезным).
Почему это "разумно просто" по сравнению с "найти.! -Читаемо ..."? Он использует команды подстановки и группировки процессов, что делает вещи более сложными и для чего, возможно, не требуется Почему нужно использовать только POSIX-совместимые функции поиска - но одновременно использовать bash или zsh? С моей точки зрения, аргументом должна быть операционная система: GNU / Linux против BSD против macOS. Как ваше решение лучше, чем ответ Джонатана Лефферса? Добавлено гораздо больше сложностей / гораздо больше текста для чтения без каких-либо существенных преимуществ.
С моей точки зрения, проблема "не заставляет замолчать все ошибки, в которых отказано в разрешении", может быть ошибкой переноса, или ошибкой в macOS, или ошибкой в базовой файловой системе, но не является общим аргументом против "find.! -Читаемым". .. ". Или не аргумент против этого в среде GNU / Linux.
POSIX явно требует разрешения для execute/search режиме файлов, чтобы «искать» каталог (извлекать иноды содержащихся файлов). find делает это для того, чтобы спуститься в подкаталог (в дополнение к требованию разрешения на read для перечисления файлов в каталоге). Это не ошибка или ошибка переноса.
Помимо обсуждения GNU / Linux и POSIX-среды, я не вижу, как добавление параметров командной строки к команде find «загрязняет», «затеняет реальное намерение» или затрудняет его расширение, особенно когда сравнивается напрямую с альтернативными решениями, включающими конвейеры, дополнительные утилиты, перенаправление потока ошибок и т. д.
Этот ответ напоминает мне о stackoverflow.com/a/1732454/292408
GNU find может быть установлен на macOS: brew install findutils .

Как я могу исключить все сообщения об отказе в разрешении из «поиска»?

17 ответов

POSIX-совместимые решения:

Заметки по существующим ответам:

Простой ответ:

Надежный ответ для GNU find:

Надежный ответ, который работает с любым совместимым с POSIX find (GNU, OSX/BSD и т.д.)

Ещё вопросы

Надежный ответ для GNU `find`:

Надежный ответ, который работает с любым совместимым с POSIX `find` (GNU, OSX/BSD и т.д.)