Копирование файлов из большого количества подпапок.

избегая создания дерева директорий.

Делается find-ом. Чё за теги такие дурацкие: копирование, копирование файлов, терминал, файл? По ним к тебе «спецы» точно не прибегут.

А поподробнее

find /your_root_dir -type f | xargs cp your_target_dir

А поподробнее

Подробнее: меняешь теги в «теме» на: bash, cp, find и гуляешь по ним.

xargs cp

Чем -exec cp '{}' your_target_dir не угодил?

почему не угодил? есть же больше одного верного способа.

а что ты будешь делать с совпадающими именами файлов?

а что ты будешь делать с совпадающими именами файлов?

Есть же cp --backup=numbered !

cp src/**/* dst/

почему не угодил?

Потому что xargs cp your_target_dir сделает: cp your_target_dir file1 file2 ... то есть

есть же больше одного верного способа.

ваш способ не верен.

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

find /your_root_dir -type f | xargs cp your_target_dir

Но и это тоже плохо: если файлов по-настоящему много, может произойти переполнение строки аргументов. xargs -n1000 лучше, но тоже плохо если в именах файлов есть пробелы и прочий мусор.

xargs cp your_target_dir сделает: cp your_target_dir file1 file2

Кстати, верно.

Кстати, верно.

Зато не верно ваше:

если файлов по-настоящему много, может произойти переполнение строки аргументов.

xargs сделан был в том числе и для предотвращения этого. С появлением в стандарте posix у find опции -exec cmd +, большинство применений xargs стало не нужным, кроме возможности сделать указанную задачу — поместить аргумент у команды после считанных.

xargs сделан был в том числе и для предотвращения этого.

Это каким образом, интересно? Если, например, cp в моей системе собран принимать не более 1024 символов, как, по твоему предположению, ксаргс об этом узнает?

Это каким образом, интересно?

Это системозависимо. Можно так: (это из моего порта https://git.busybox.net/busybox/tree/findutils/xargs.c )

/* COMPAT:  SYSV version defaults size (and has a max value of) to 470.
   We try to make it as large as possible. */
#if !defined(ARG_MAX) && defined(_SC_ARG_MAX)
#define ARG_MAX sysconf (_SC_ARG_MAX)
#endif
#ifndef ARG_MAX
#define ARG_MAX 470
#endif

Подобный костыль - ярчайшее подтверждение наличия проблемы :). А выхлоп https://www.google.com/search?q=argument line too long показывает, что решает он её хреновато.

cp в моей системе собран принимать не более 1024 символов

Это как? В смысле, сам cp здесь вроде ни при чём, ARG_MAX для exec* же. А cp другие процессы, если не ошибаюсь, не запускает

Я, если честно, не в курсе, как устроен cp изнутри. Но на грабли с ксаргсом и переполнением наступал не раз.

Лол, и ведь посмотреть даже нельзя:

git clone --recursive git://git.sv.gnu.org/coreutils
...
error: object a6727941433ee1c91a20ede6cb381af1d18c566d: missingSpaceBeforeDate: invalid author/committer line - missing space before date
fatal: fsck error in packed object
...

Подобный костыль - ярчайшее подтверждение наличия проблемы

Вы сами то приведенный url прочитали? Там честно предупреждали, что -i работает криво и давно юзать его не рекомендуется.

find /dir/where/ -exec cp --target-directory=DIRECTORY {} +

Так себе костыль, количество ругани будет впечатляющим:

$ mkdir a b ta
$ touch a/a 
$ cd b
$ ln -s ../a/a
$ cd ..
$ find . -exec cp --target-directory=ta {} +
cp: omitting directory '.'
cp: omitting directory './a'
cp: omitting directory './ta'
cp: omitting directory './b'
cp: will not overwrite just-created 'ta/a' with './b/a'

Ну так надо добавить к вызову финда всякие -type f и прочее по вкусу и ситуации, а не тупо копировать всякий код с лора в рутовую консоль на проде :)

а не тупо копировать

Воот. А народ тащится от минималистических однострочников. Даже вон запоминает подпорки типа "--target-directory=DIRECTORY" :) . Удручает.

Вы сами то приведенный url прочитали? Там честно предупреждали

Читал ли я, как именно в бизибоксе закостылили xargs и какими именно ограничениями и несовместимостями он отягощён? Ну разумеется, и каждый день перечитываю. Что вообще может быть интереснее и насущнее?

Читал ли я, как именно в бизибоксе закостылили xargs и какими именно ограничениями и несовместимостями он отягощён?

Эта проблема не имеет отношения к топику, но можно и об этом поговорить.

Ну разумеется, и каждый день перечитываю. Что вообще может быть интереснее и насущнее?

А почитать вообще бы вам не помешало. А то у вас странные представления о внутреннем устройcтве утилит. Маленькая подсказка:

если, например, cp в моей системе собран принимать не более 1024 символов,

Логически вытекает, что вообще ничего делать нельзя, вдруг у вашей cp там вообще 99?

Не знаю никого, ктобы запомнил про –target-directory=DIRECTORY кроме меня :) А я её запомнил потому, что она хорошо работает с find -exec и xargs, которые опять же я люблю а другие не очень и предпочитают циклы баша или что похуже.

xargs, которые опять же я люблю

Тут ранее бывал тоже один любитель xargs, который с удивлением узнал, что без -d '\n' юзать нельзя.

$ touch 'a b'
$ find . -type f | xargs -n 1 echo 
./a
b

а другие не очень и предпочитают циклы баша или что похуже.

Дык, это позволяет сделать задачу хорошо, универсально, расширяемо, шаблонируемо под небольший изменения и т д. А где ещё есть это самое --target-dir ?

без -d ‘\n’ юзать нельзя.

Его и с -d ‘\n’ юзать нельзя, по крайней пере с именами файлов.

А где ещё есть это самое –target-dir ?

Где мне надо, там везде есть. А там где нет - выдаст читаемую ошибку, что тоже важно.

А то у вас странные представления о внутреннем устройcтве утилит.

Да. Короткий эксперимент подтвердил, что я неправ. Но исходникам бизибокса на ночь все равно предпочту другое чтение :).

Его и с -d ‘\n’ юзать нельзя, по крайней пере с именами файлов.

Проблема в том, что утилит с аналогом -print0 шиш да маленько.

Где мне надо, там везде есть.

Ничего не понял. Этот ваш --target-dir, по-моему, ещё реже, чем -print0 встречается.