Сергей, Валерий, извиняюсь опять, поскольку fc-cache это fontcontfig, то неправильно привязываться к fints.dir, так как там его может и не быть, см. http://lists.altlinux.org/pipermail/devel/2011-August/191583.html поэтому предлагаю второй вариант. #!/bin/sh -efu egrep -o '^/usr/share/fonts/.+/.+\.(ttf|otf|ttc|pcf|pcf.gz|afm|pfb)$' | sed -e 's,/[^/]*$,,' | sort -u | while read -r font_dir; do [ -d "$font_dir" ] && fc-cache "$font_dir" done
Created attachment 5035 [details] fontconfig.filetrigger прикладываю fontconfig.filetrigger
А может все-таки проще grep -qs '^/usr/share/fonts/' && /etc/firsttime.d/fontconfig ||: ?
(В ответ на комментарий №2) > А может все-таки проще > grep -qs '^/usr/share/fonts/' && /etc/firsttime.d/fontconfig ||: Разница во времени выполнения составляет более 500 раз (повторные прогоны, файловая система закеширована): $ time sudo ls /usr/share/fonts |./fontconfig.filetrigger sudo ls /usr/share/fonts 0,00s user 0,01s system 75% cpu 0,011 total ./fontconfig.filetrigger 0,00s user 0,00s system 36% cpu 0,011 total $ time sudo /etc/firsttime.d/fontconfig Updating fonts cache: [ DONE ] sudo /etc/firsttime.d/fontconfig 4,74s user 0,12s system 70% cpu 6,887 total
(В ответ на комментарий №3) > более 500 раз Это сравнение ежа с ужом. Для такого мой вариант должен обрабатывать в 500 раз больше шрифтов. Логично, не правда ли? Единственный вариант, когда это может быть если в /usr/share/fonts обновились файлы, для которых fc-cache не нужно запускать вообще.
Created attachment 5036 [details] fontconfig.filetrigger.zerg
нет :) Сергей, вы не обратили внимания на опцию --force в /etc/firsttime.d/fontconfig. именно она дает разницу в 500 раз, так как делает ненужную работу. как вам такой вариант? #!/bin/sh -efu grep -qs '^/usr/share/fonts/' && /usr/bin/fc-cache --system-only
(В ответ на комментарий №6) > --force > именно она дает разницу в 500 раз, так как делает ненужную работу. Для этого примерно в 500 раз каталогов больше должно сканироваться. Это возможно только когда сканировать ничего не надо. В общем, повторил то же самое другими словами.
(В ответ на комментарий №6) > как вам такой вариант? > #!/bin/sh -efu > grep -qs '^/usr/share/fonts/' && /usr/bin/fc-cache --system-only Не против. P.S. Просто я за надежность, особенно, если ничего не стОит.
(В ответ на комментарий №7) > (В ответ на комментарий №6) > > --force > > именно она дает разницу в 500 раз, так как делает ненужную работу. > Для этого примерно в 500 раз каталогов больше должно сканироваться. прошу прощения, но как я понимаю, что с --force, что без, fc-cache сканирует одинаковое число каталогов, но без --force, если в /var/cache/fontconfig кеш уже найден, то fc-cache пойдет дальше, а с --force перегенерирует этот кеш заново. т.е. без --force fc-cache создаст кеш только для свежеустановленных пакетов, а с --force будет повторно обрабатывать все установленные шрифты. без --force fc-cache отрабатывает мгновенно, а с --force он требует 5 сек. для `rpm -qa| grep fonts- | wc`=62 пакетов скриптов на машине athlonII250 12Gb memory. Тогда на нетбуке или древней машине может и до минуты отрабатывать. Что неприемлемо.
(В ответ на комментарий №9) > с --force будет повторно обрабатывать все установленные шрифты. Да > без --force fc-cache отрабатывает мгновенно Нет, т.к. grep отсеет эти случаи. >, а с --force он требует 5 сек. Это и есть время его работы, а 62 пакета Китайских и др. шрифтов даже идиот ставить не будет. > может и до минуты отрабатывать. Что неприемлемо. По мне это приемлимо, учитывая, что все равно шрифтов будет гораздо меньше.
Валер, ты как насчет #!/bin/sh -efu grep -qs '^/usr/share/fonts/' && /usr/bin/fc-cache --system-only ?
(В ответ на комментарий №10) > а 62 пакета Китайских и др. шрифтов даже идиот ставить не будет. примеры из жизни есть. > > без --force fc-cache отрабатывает мгновенно > Нет, т.к. grep отсеет эти случаи. > >, а с --force он требует 5 сек. > Это и есть время его работы, при чем здесь grep? grep сработает, даже если установился или удалился только один шрифт. а перегенерировать кеш заново для всех остальных шрифтов -- какой в этом смысл? зря только время тратить.
(В ответ на комментарий №12) > (В ответ на комментарий №10) > > а 62 пакета Китайских и др. шрифтов даже идиот ставить не будет. > примеры из жизни есть. Ну, там машина вряд ли слабая. > при чем здесь grep? grep сработает, даже если установился или удалился только > один шрифт. Даже если у нас появиться такой пакет, то его одного можно в расчет не принимать. > а перегенерировать кеш заново для всех остальных шрифтов > -- какой в этом смысл? > зря только время тратить. Случаи разные бывают. Так надежнее.
В общем, все предложенные реализации более корректны, чем имеющаяся, так что какая бы реализация ни была выбрана, это уже шаг вперед. Суть моих замечаний в том, что некоторые из обсуждаемых здесь реализация злоупотребляют опцией --force, см. man fc-cache -f Force re-generation of apparently up-to-date cache files, over‐ riding the timestamp checking. что приведет к слишком тормозной реализации. та же реализация, но без --force будет такой же корректной, но в сотни раз быстрее из-за отсутствия там re-generation of apparently up-to-date cache files.
(В ответ на комментарий №14) > без --force да я ж писал, что не против
(В ответ на комментарий №15) > да я ж писал, что не против Сорри. Прошу прощения.
как там с улучшенным файлтриггером? я уже больше сотни пакетов повыкладывал в расчете на этот файлтриггер, не говоря уже и что полиси под него написал, в общем, нужен срочно.
Валер, ты доступен? А то я сделаю.
fontconfig-2.8.0-alt8 -> sisyphus: * Wed Aug 17 2011 Valery Inozemtsev <shrek@altlinux> 2.8.0-alt8 - updated fontconfig.filetrigger (closes #25992)
Ты uniq после sort забыл
fontconfig-2.8.0-alt8 -> t6: * Wed Aug 17 2011 Valery Inozemtsev <shrek@altlinux> 2.8.0-alt8 - updated fontconfig.filetrigger (closes #25992)
(В ответ на комментарий №20) > Ты uniq после sort забыл Фигню написал, извиняюсь