> Для init.d bash как раз не рекомендуются, есть специальные шеллы с > минимизацией количества форков при загрузке..
Признаться, время загрузки совсем не интересует, секундой больше или меньше для меня не принципиально. Вопрос в удобстве поддержки скриптов. > Насчет сочувствия - сочувствую тем кто не читает вообще никакие доки, > даже howto и faq, не умеет пользоваться гуглом и думает что в этом > виноват bash. > Эта проблема есть вообще _везде_ - ограничение на длину команды(без > которого было бы всё _намного_ хуже), ядро эти "*" не понимает, bash > заменяет такие маски на полный список соотв. файлов, длина команды > получается адской. Тогда по идее rm -rf /test/test_10000/ должно работать быстро, поскольку список файлов не передается... Здесь-то что мешает? > Решение: > find /test/test_10000/ -type f |xargs rm > Немного более кошерно: > find /test/test_10000/ -type f -print0 |xargs -0 rm -f > Вообще это может и сам find: > find /test/test_10000/ -type f -delete > Но xargs более универсальная вещь. > Глубина рекурсии для поиска по умолчанию не ограничена, чтобы не трогать > подкаталоги: > find /test/test_10000/ -type f -maxdepth=1 |xargs rm > > > Насчет вашего варианта на тикле - он хуже(съест дофига ram, если файлов > много), и явно медленнее решения с find. Интересно, откуда это следует. Буду пробовать. Сдается мне, что если запускаю один интерпретатор тикля, то это будет не медленнее варианта с find, который тоже еще надо проверить по скорости. > и, кстати, на bash, вы могли бы написать аналогично: > cd /test/test_000000/ > for f in $(ls ) > do > rm "$f" > done > Если не хочеться менять каталог - добавьте путь в ls и rm или > используйте файл: > for f in $(find /test/test_000/ -type f); do rm "$f"; done > > Но это очень не эффективно - по форку на файл. Идея понятна. Только на тикле это рабочее решение, а на баше - лишь пример. Хотя если в используемом шелле подобные команды встроены, то и проблемы быть не должно.
