LINUX.ORG.RU

Ответ на: комментарий от zolden

вы не поняли. команда find выводит в терминал пути к найденным файлам, а мне надо, чтобы эти пути сразу подставлялись в команду cp

slonzhenya ()
Ответ на: комментарий от slonzhenya

проблем бы небыло

какая разница диск или каталог? И там и там рекурсивный обход используется

zolden ★★★★★ ()
Ответ на: комментарий от slonzhenya

Упрётся в лимит длины комстроки.

anonymous ()
Ответ на: комментарий от zolden

ты не знаешь, что длина команды ограничена ядром в 64 что-ли килобайт? ты не согласен с фактом, что просто выводить в stdout (как это делает find) гораздо быстрее, чем хранить все названия файлов в памяти и составлять из них одну строку/огромный массив строк (как это будет делать шелл)?

maloi ★★★★★ ()
Ответ на: комментарий от maloi

У тебя верные предпосылки, но неверные выводы.
Давай, признай уже, что про дикие тормоза ты для красного словца сказанул

zolden ★★★★★ ()
Ответ на: комментарий от zolden

проверил сейчас - действительно достаточно быстро выдает сообщение об ошибке, видимо в баше сделали специальную проверку, чтоб не тормозило часами, как пару лет назад, а сразу выходило с ошибкой.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

Нет, ты в сторону ушёл.
Длина строки аргументов это отдельный вопрос, и для ТС он неактуален (тут мне можно сказать повезло, и рекурсивный глоббинг в таком виде тут самый простой, интуитивно понятный и изящный вариант)
Но дикими тормозами тут в любом случае не пахнет, основное время уйдет на копирование, а не на построение списка файлов. Хранить/оперировать несколькими килобайтами в памяти - это даже для калькулятора не проблема, не говоря уже про кампутер.

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Длина строки аргументов это отдельный вопрос, и для ТС он неактуален

если ему один раз повезло, это не значит, что повезет во второй раз.

Но дикими тормозами тут в любом случае не пахнет, основное время уйдет на копирование, а не на построение списка файлов. Хранить/оперировать несколькими килобайтами в памяти - это даже для калькулятора не проблема, не говоря уже про кампутер.

для килобайтов как раз проблем никаких нет, а вот когда счет идет мегабайтами - если список составлять в лоб, без задействования вменяемого алгоритма, то эти мегабайты будут не одну тысячу раз скопированы, а это уже заметное время, после которого шелл не сможет сделать exec и копирования не будет, и тормозов от него, естественно, тоже.

впрочем, ты можешь и дальше считать, что шелл идеален и не может тормозить.

maloi ★★★★★ ()
Ответ на: комментарий от maloi

для килобайтов как раз проблем никаких нет, а вот когда счет идет мегабайтами - если список составлять в лоб, без задействования вменяемого алгоритма, то эти мегабайты будут не одну тысячу раз скопированы, а это уже заметное время, после которого шелл не сможет сделать exec и копирования не будет, и тормозов от него, естественно, тоже.
впрочем, ты можешь и дальше считать, что шелл идеален и не может тормозить.

Слушай, давай без эмоций и твоих домыслов.
Не знаю как там насчёт баша, а в zsh рекурсивный глоббинг используется вполне эффективно
Давай предлагай методику тестирования, пока я тебя не занёс в список «Теоретиков»

zolden ★★★★★ ()
Ответ на: комментарий от zolden

ты не прав. буквально на прошлой недели починили приложение, пытавшееся сгенерировать полный список файлов вместо того чтобы обрабатывать их по одному, и в результате тупившее над этой задачкой по 20-30 минут. ты же не знаешь какие у ТС файлуха и обьемы данных.

звездочки в комстроке - это подпорка для неосиливших файнд. использовать ее можно только чтобы не писать полные имена файлов если их немного и это точно известно.

val-amart ★★★★★ ()
Ответ на: комментарий от zolden

а где видно что у ТС зсш? единственное вменяемое предположение о неизвестной ПОСИКС среде - это что шелл sh. похоже, ты админ локалхоста.

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

О, ещё один теоретик подтянулся. Тоже пишешь скрипты за деньги или на АЭС?
Давай без этих вот побасенок про POSIX, нормальный админ всегда знает что у него где стоит и какие инструменты в наличии.
Универсальных решений не бывает, и если можно сделать проще и быстрее - я буду делать проще и быстрее.

zolden ★★★★★ ()
Ответ на: комментарий от zolden

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

maloi ★★★★★ ()
Ответ на: комментарий от maloi

в таких случаях

мы всё ещё про рекурсивный глоббинг? встроенный в баш? (в баше он появился только начиная с 4й версии)

zolden ★★★★★ ()
Ответ на: комментарий от slonzhenya

можно тогда ущё sed'ом экранировать пробелы )

Напиши уже программу на сишечьке, чо. Блин, один раз прочитать два мана, а потом не тупить на форумах, неужели это так сложно?

baverman ★★★ ()
Ответ на: комментарий от slonzhenya

можно тогда ущё sed'ом экранировать пробелы )

Можно, но не нужно:

find /media/DISK_ -name '*.emf' -print0 | xargs -0 cp -t ~/time
man find, man xargs

dexpl ★★★★★ ()
Ответ на: комментарий от zolden

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

maloi ★★★★★ ()
Ответ на: комментарий от slonzhenya

если поставленную задачу можно решить штатными средствами.

Бинго! Однако ты забил на все прекрасные штатные средства озвученные в треде.

baverman ★★★ ()
Ответ на: комментарий от baverman

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

slonzhenya ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.