Вопросы Теги

Сценарий для подсчета файлов, соответствующих шаблону в подкаталогах

Можно найти общее описание CFS здесь. Это не вес/ограничение, базирующийся в том смысле, что это не основано на распределении кванта времени выполнения среди самых пригодных процессов. Вы могли бы хотеть читать о том, как хорошие уровни реализованы также, который ясно даст понять различие.

1
17.10.2014, 02:25
3 ответа

Ответ, данный kev, повредится на файлах с новыми строками на имя. Можно выполнить в этом чистом bash:

shopt -s nullglob dotglob globstar
set -- **/*.pdf **/*.tex
echo "$#"
8
27.01.2020, 23:10
  • 1
    Действительно ли необходимо сравнить скорость рекурсивного обхода ответвления каталога и поиска в текущем каталоге? –  manatwork 22.12.2011, 11:14
  • 2
    @manatwork не понял, что это было также subdirs, фиксируя теперь. –  Chris Down 22.12.2011, 11:17
  • 3
    Хорошо, просто еще одно слово: ничего себе! –  manatwork 22.12.2011, 11:25
  • 4
    @ChrisDown: Вы могли объяснить это set и $#? –  pbm 23.03.2012, 17:46
  • 5
    @pbm - Что Вы не понимаете? set в справедливо надежно объясняют help set и $# содержит количество аргументов. –  Chris Down 23.03.2012, 21:22

find хорошо работает мне:

$ find . -name '*.pdf' -o -name '*.tex' | wc -l
75
$ find . -name '*.pdf' | wc -l
16
$ find . -name '*.tex' | wc -l
59
$ echo $((16+59))
75

Править:
Обработать особый случай: newline в имени файла

$ find . \( -name '*.pdf' -o -name '*.tex' \) -printf x | wc -c
6
27.01.2020, 23:10
  • 1
    Это повредится для файлов с новыми строками в их имени файла. –  Chris Down 22.12.2011, 10:36
  • 2
    Это действительно повреждается, поскольку можно вполне ясно видеть выполнение следующего кода: > $'foo\nbar.pdf' ; > $'baz\nqux.tex' ; find . -name '*.pdf' -o -name '*.tex' | wc -l - ответ 4, который не корректен (существует два файла). –  Chris Down 22.12.2011, 10:47
  • 3
    @ChrisDown. Вы правы. –  kev 22.12.2011, 10:54
  • 4
    @ChrisDown: Я всегда отказываюсь сделать код более сложным только для принятия во внимание "новых строк в именах файлов", потому что я никогда не видел такой случай в повседневных ситуациях. Очевидно, чтобы код опубликовал, это корректно для принятия во внимание каждой возможности. Вы знаете о случаях, где "новые строки в именах файлов" не, создают по ошибке или сознательно протестировать программное обеспечение? –  enzotib 22.12.2011, 11:15
  • 5
    @enzotib я видел его многократно, но только людьми, использующими менеджеров по графическому файлу. Часто это происходит, когда они идут для вставки чего-то из другого источника, который содержит новые строки в имя файла, и они не ожидают, что новые строки все еще будут присутствовать. –  Chris Down 22.12.2011, 11:16

Я рекомендовал бы (при наличии) использовать locate вместо находки. Вы запросили бы базу данных, и результаты будут мгновенны и нет практически никакой нагрузки на систему. Хотя база данных только обновляется, когда Ваша система работает updatedb таким образом, если бы Вы хотели до второй информации, то необходимо было бы удостовериться, что выполнили ее сначала, и она создаст нагрузку для системы, но, она зависит от того, как Вы намереваетесь использовать свой поиск.

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

system1:/unix.stackexchange # locate *.tex *.pdf | grep unix.stack.*
   /unix.stackexchange/access_me/1/file.pdf
   /unix.stackexchange/access_me/1/file.tex
0
27.01.2020, 23:10

Теги

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