объединение команд

-exec

cp /media/DISK_/**/*.emf destination
если это баш то нужно включить рекурсивный глоббинг

man find xargs

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

find | xargs cp -t /tmp

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

Чтобы бы(д)ло «понятнее» :3

файлы раскиданы по разным каталогам на диске в 1,5 ТБ. Были бы они в одном каталоге - проблем бы небыло.

а также словить дикие тормоза и ошибки, если файлов over 9000

всё, что было нужно

cp $(find /media/DISK_ -name '*.emf') ~/time/

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

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

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

дикие тормоза

тесты будут или это только догадки?

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

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

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

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

> cp $(find /media/DISK_ -name '*.emf') ~/time/

надеюсь, у тебя там нет файлов/директорий с пробелами ;)

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

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

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

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

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

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

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

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

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

и чем же будут опасны пробелы при таком подходе?

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

> и чем же будут опасны пробелы при таком подходе?

проверь ;)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-t

Век живи, век учись. Однако, хоть какая-то польза от таких топиков есть.

Это что-то из свежего похоже. Нучо, круто.

Век живи, век учись

+1, сам узнал про -t только что (спасибо, sdio). val-amart, "-t" — опция GNU, насколько я понял

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