для vs знайти у Bash

При перегляді файлів є два способи:

1. використовувати for-loop:

   for f in *; do
       echo "$f"
   done

2. використання find:

   find * -prune | while read f; do 
       echo "$f"
   done

Якщо припустити, що ці дві петлі знайдуть однаковий список файлів, які відмінності у цих двох варіантах у виконанні та обробці?

1.

Перший:

for f in *; do
  echo "$f"
done

не вдається для файлів, що викликаються -n, -eі варіантів, таких як -neneі з деякими розгортаннями bash, з назви файлів, що містять зворотні риски.

Секунда:

find * -prune | while read f; do 
  echo "$f"
done

НЕ може навіть більше випадків (файли називаються !, -H, -name, (, імена файлів , які починаються або кінець з пробілами або містять символи нового рядка ...)

Це оболонка, яка розширюється *, findне робить нічого, крім друкує файли, які вона отримує як аргументи. Ви також можете використати, printf '%s\n'натомість, як printfвбудований, також уникне занадто великої кількості помилок потенційної помилки.

2.

Розширення *відсортовано, ви можете зробити це трохи швидше, якщо сортування вам не потрібно. В zsh:

for f (*(oN)) printf '%s\n' $f

або просто:

printf '%s\n' *(oN)

bashНаскільки я не можу сказати, еквівалент не має, тому вам доведеться вдаватися find.

3.

find . ! -name . -prune ! -name '.*' -print0 |
  while IFS= read -rd '' f; do
    printf '%s\n' "$f"
  done

(вище з використанням -print0нестандартного розширення GNU / BSD ).

Це все ще включає нерест команди find і використання повільного while readциклу, тому, ймовірно, це буде повільніше, ніж використання forциклу, якщо список файлів не є величезним.

4.

Крім того, на відміну від розширення підстановки на оболонку, findбуде виконувати lstatсистемний виклик кожного файлу, тому навряд чи несортування компенсує це.

З GNU / BSD find, цього можна уникнути, використовуючи їх -maxdepthрозширення, що призведе до оптимізації, зберігаючи lstat:

find . -maxdepth 1 ! -name '.*' -print0 |
  while IFS= read -rd '' f; do
    printf '%s\n' "$f"
  done

Тому що findпочинається виведення імен файлів, як тільки вони знаходять їх (за винятком буферизації виводу stdio), де це може бути швидше, якщо те, що ви робите в циклі, займає багато часу, і список імен файлів перевищує буфер stdio (4 / 8 кБ). У цьому випадку обробка в циклі розпочнеться до findтого, як закінчиться пошук усіх файлів. У системах GNU та FreeBSD ви можете використовувати stdbufдля того, щоб це відбулося швидше (вимкнення буферизації stdio).

5.

POSIX / стандартний / портативний спосіб запуску команд для кожного файлу find- це використання -execпредиката:

find . ! -name . -prune ! -name '.*' -exec some-cmd {} ';'

У випадку, echoоднак, це менш ефективно, ніж робити циклічне завершення в оболонці, оскільки оболонка матиме вбудовану версію, echoтоді як findпотрібно буде породити новий процес та виконати /bin/echoв ньому для кожного файлу.

Якщо вам потрібно виконати кілька команд, ви можете зробити:

find . ! -name . -prune ! -name '.*' -exec cmd1 {} ';' -exec cmd2 {} ';'

Але будьте обережні, що cmd2виконується лише у випадку cmd1успіху.

6.

Канонічним способом запуску складних команд для кожного файлу є виклик оболонки за допомогою -exec ... {} +:

find . ! -name . -prune ! -name '.*' -exec sh -c '
  for f do
    cmd1 "$f"
    cmd2 "$f"
  done' sh {} +

На той час ми повернулися до ефективності, echoоскільки ми використовуємо shвбудований один і -exec +версія породжує shякомога менше.

7.

У моїх тестах на каталозі з 200.000 файлів із короткими іменами на ext4 zshодин з них (параграф 2) є найшвидшим, за ним слідує перший простий for i in *цикл (хоча, як завжди, bashнабагато повільніше, ніж інші оболонки для цього).

Я спробував це в каталозі з 2259 записами і використав timeкоманду.

Вихід time for f in *; do echo "$f"; done(мінус файли!):

real    0m0.062s
user    0m0.036s
sys     0m0.012s

Вихід time find * -prune | while read f; do echo "$f"; done(мінус файли!):

real    0m0.131s
user    0m0.056s
sys     0m0.060s

Я виконував кожну команду кілька разів, щоб усунути пропуски кешу. Це говорить про те, що тримати його в bash(для i in ...) швидше, ніж використовувати findта перекладати вихід (до bash)

Тільки для повноти я кинув трубу find, оскільки у вашому прикладі це зовсім зайве. Вихід просто find * -prune:

real    0m0.053s
user    0m0.016s
sys     0m0.024s

Крім того, time echo *(вихід не відокремлений новим рядком, на жаль):

real    0m0.009s
user    0m0.008s
sys     0m0.000s

На даний момент я підозрюю, що причина echo *швидша - це не виведення стільки нових рядків, тому результат не прокручується так сильно. Давайте перевіримо ...

time find * -prune | while read f; do echo "$f"; done > /dev/null

врожайність:

real    0m0.109s
user    0m0.076s
sys     0m0.032s

а time find * -prune > /dev/nullврожайність:

real    0m0.027s
user    0m0.008s
sys     0m0.012s

та time for f in *; do echo "$f"; done > /dev/nullврожайність:

real    0m0.040s
user    0m0.036s
sys     0m0.004s

і нарешті: time echo * > /dev/nullурожайність:

real    0m0.011s
user    0m0.012s
sys     0m0.000s

Деякі з варіацій можна пояснити випадковими факторами, але це здається зрозумілим:

• вихід повільний
• трубопроводи коштують трохи
• for f in *; do ...проходить повільніше, ніж find * -pruneсамостійно, але для конструкцій, що входять вище, швидше.

Крім того, видається, що обидва підходи обробляють імена з пробілами просто чудово.

Редагувати:

Затримки для find . -maxdepth 1 > /dev/nullVS. find * -prune > /dev/null:

time find . -maxdepth 1 > /dev/null:

real    0m0.018s
user    0m0.008s
sys     0m0.008s

find * -prune > /dev/null:

real    0m0.031s
user    0m0.020s
sys     0m0.008s

Отже, додатковий висновок:

• find * -pruneповільніше, ніж find . -maxdepth 1- у першому, оболонка обробляє глобул, потім будує (великий) командний рядок для find. NB: find . -pruneповертається просто ..

Більше тестів time find . -maxdepth 1 -exec echo {} \; >/dev/null:

real    0m3.389s
user    0m0.040s
sys     0m0.412s

Висновок:

• найповільніший спосіб зробити це до цих пір. Як було зазначено в коментарях до відповіді, де пропонувався такий підхід, кожен аргумент породжує оболонку.

Я б точно пішов з пошуку, хоча я змінив би вашу знахідку лише на це:

find . -maxdepth 1 -exec echo {} \;

Продуктивність мудра, findнабагато швидша в залежності від ваших потреб. Те, що ви зараз маєте з forним, відображатиме лише файли / каталоги в поточному каталозі, але не вміст каталогів. Якщо ви використовуєте find, він також відображатиме вміст підкаталогів.

Я говорю знахідка краще , так як з вашим повинно бути розширена першим , і я боюся , що якщо у вас є каталог з величезною кількістю файлів , які він може дати помилку список аргументів занадто довго . Те саме стосуєтьсяfor*find *

Наприклад, в одній із систем, якими я зараз користуюся, є пара каталогів із понад 2 мільйонами файлів (<100k кожна):

find *
-bash: /usr/bin/find: Argument list too long

find * -prune | while read f; do 
    echo "$f"
done

- марне використання find- те, що ви говорите, ефективно "для кожного файлу в каталозі ( *), не знаходите жодних файлів. Також це не є безпечним з кількох причин:

• Підмостки в доріжках обробляються спеціально без -rможливості read. Це не проблема з forциклом.
• Нові рядки в шляхах порушують будь-яку нетривіальну функціональність всередині циклу. Це не проблема з forциклом.

Обробка будь-якого імені файлу з findце важко , так що ви повинні використовувати forопцію циклу щоразу , коли це можливо тільки за цієї причини. Крім того, запуск зовнішньої програми типу, як findправило, буде повільніше, ніж виконання внутрішньої циклу команди for.

Але ми - присоски для питань продуктивності! Цей запит на експеримент робить принаймні два припущення, які роблять його не дуже правильним.

A. Припустимо, що вони знаходять однакові файли ...

Ну, вони будуть знаходити одні і ті ж файли , у - перших, тому що вони обидва Перебір ж Glob, а саме *. Але find * -prune | while read fстраждає від кількох недоліків, завдяки яким він не може знайти всі очікувані файли:

1. Пошук POSIX не гарантовано приймає більше ніж один аргумент шляху. Більшість findреалізацій є, але все ж на це не варто покладатися.
2. find *може зламатися при ударі ARG_MAX. for f in *не буде, тому що ARG_MAXстосується execне вбудованих.
3. while read fможе розірватися з назви файлів, починаючи і закінчуючи пробілом, який позбавиться. Ви можете подолати це while readза допомогою параметра за замовчуванням REPLY, але це все одно не допоможе вам, коли мова йде про назви файлів з новими рядками в них.

B. echo. Цього ніхто не збирається робити лише для того, щоб повторити назву файлу. Якщо ви цього хочете, просто виконайте одну з таких дій:

printf '%s\n' *
find . -mindepth 1 -maxdepth 1 # for dotted names, too

Тут труба до whileциклу створює неявну підзаглушку, яка закривається, коли цикл закінчується, що для деяких може бути неінтуїтивним.

Щоб відповісти на запитання, ось результати в моєму каталозі, який містить 184 файли та каталоги.

$ time bash -c 'for i in {0..1000}; do find * -prune | while read f; do echo "$f"; done >/dev/null; done'

real    0m7.998s
user    0m5.204s
sys 0m2.996s
$ time bash -c 'for i in {0..1000}; do for f in *; do echo "$f"; done >/dev/null; done'

real    0m2.734s
user    0m2.553s
sys 0m0.181s
$ time bash -c 'for i in {0..1000}; do printf '%s\n' * > /dev/null; done'

real    0m1.468s
user    0m1.401s
sys 0m0.067s

$ time bash -c 'for i in {0..1000}; do find . -mindepth 1 -maxdepth 1 >/dev/null; done '

real    0m1.946s
user    0m0.847s
sys 0m0.933s

find *не працюватимуть правильно, якщо *виробляються маркери, схожі на предикати, а не на шляхи.

Ви не можете використовувати звичайний --аргумент, щоб виправити це, оскільки --вказує кінець параметрів, а параметри пошуку знаходяться перед шляхами.

Щоб виправити цю проблему, можна скористатися find ./*натомість. Але тоді це не створює абсолютно таких же рядків, як for x in *.

Зауважте, що find ./* -prune | while read f ..насправді функція сканування не використовується find. Саме глобусний синтаксис ./*фактично обходить каталог і генерує імена. Тоді findпрограма повинна буде виконати хоча б statперевірку кожного з цих імен. Ви маєте накладні витрати на запуск програми та отримання доступу до цих файлів, а потім виконання вводу-виводу для читання її результатів.

Важко уявити, як це може бути що-небудь, але менш ефективне, ніж for x in ./* ....

Ну для початківців forце ключове слово оболонки, вбудоване в Bash, хоча findце окремий виконуваний файл.

$ type -a for
for is a shell keyword

$ type -a find
find is /usr/bin/find

forЦикл буде знайти тільки файли з globstar характеру , коли вона розширюється, вона не буде рекурсією в будь-каталоги , які він знаходить.

Знахідку з іншого боку також буде надано список, розширений globstar, але він буде рекурсивно знаходити всі файли та каталоги нижче цього розширеного списку і передавати їх до whileциклу.

Обидва ці підходи можуть вважатися небезпечними в тому сенсі, що вони не обробляють шляхи або назви файлів, які містять пробіли.

Ось про все, що я можу подумати, варто прокоментувати ці 2 підходи.

Якщо всі файли, повернені знахідкою, можуть бути оброблені однією командою (очевидно, що не стосується вашого прикладу echo вище), ви можете використовувати xargs:

find * |xargs some-command

Роками я цим користуюся: -

find . -name 'filename'|xargs grep 'pattern'|more

шукати певні файли (наприклад, * .txt), які містять шаблон, який може шукати grep, і передавати його в інше, щоб він не прокручувався з екрана. Іноді я використовую трубу >>, щоб записати результати в інший файл, який я можу переглянути пізніше.

Ось зразок результату: -

./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:Message-ID: <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:In-Reply-To: <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:  <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:  <A165CE5C-61C5-4794-8651-66F5678ABCBF@usit.net>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2008-August.txt:Message-ID: <448E53556A3F442ABC58203D6281923E@hypermax>
./Documents/Organ_docos/Rodgerstrio321A/rodgersmylist/2011-April.txt:URL: http://mylist.net/private/rodgersorganusers/attachments/20110420/3f