Сначала отрежьте тривиальные, но неприменимые ответы: я не могу использовать ни трюк find+, xargsни его варианты (например, findс -exec), потому что мне нужно использовать несколько таких выражений на вызов. Я вернусь к этому в конце.

Теперь для лучшего примера давайте рассмотрим:

$ find -L some/dir -name \*.abc | sort
some/dir/1.abc
some/dir/2.abc
some/dir/a space.abc

Как передать эти аргументы program?

Просто делать это не делает трюк

$ ./program $(find -L some/dir -name \*.abc | sort)

терпит неудачу, так как programполучает следующие аргументы:

[0]: ./program
[1]: some/dir/1.abc
[2]: some/dir/2.abc
[3]: some/dir/a
[4]: space.abc

Как видно, путь с пробелом был разделен и programрассматривает его как два разных аргумента.

Цитировать пока не работает

Кажется, что начинающие пользователи, такие как я, сталкиваются с такими проблемами, как правило, произвольно добавляют кавычки, пока они, наконец, не работают - только здесь это, кажется, не помогает ...

"$(…)"

$ ./program "$(find -L some/dir -name \*.abc | sort)"
[0]: ./program
[1]: some/dir/1.abc
some/dir/2.abc
some/dir/a space.abc

Поскольку кавычки предотвращают разбиение слов, все файлы передаются как один аргумент.

Цитирование отдельных путей

Перспективный подход:

$ ./program $(find -L some/dir -name \*.abc -printf '"%p"\n' | sort)
[1]: "some/dir/1.abc"
[2]: "some/dir/2.abc"
[3]: "some/dir/a
[4]: space.abc"

Цитаты есть, конечно. Но они больше не интерпретируются. Они просто часть струн. Так что не только они не помешали разделению слов, но и попали в аргументы!

Изменить IFS

Затем я попытался поиграть с IFS. Я бы предпочел findс -print0и sortс в -zлюбом случае - чтобы у них не было проблем на «проводных путях» самих. Так почему бы не заставить слова разделить nullперсонажа и иметь все это?

$ ./program $(IFS=$'\0' find -L some/dir -name \*.abc -print0 | sort -z)
[0]: ./program
[1]: some/dir/1.abcsome/dir/2.abcsome/dir/a
[2]: space.abc

Таким образом, он все еще разделяется на пространство и не разделяется на null.

Я пытался разместить IFSназначение как в $(…)(как показано выше), так и раньше ./program. Также я попробовал другой синтаксис , как \0, \x0, \x00и цитировал с 'и "а также и без $. Казалось, ничего из этого не имеет значения ...

И здесь у меня нет идей. Я попробовал еще несколько вещей, но все, казалось, сводилось к тем же проблемам, которые перечислены.

Что еще я мог сделать? Это вообще выполнимо?

Конечно, я мог бы programпринять шаблоны и выполнить сам поиск. Но это двойная работа, когда он привязан к определенному синтаксису. (Как насчет предоставления файлов, grepнапример?).

Также я мог бы programпринять файл со списком путей. Затем я могу легко вывести findвыражение в некоторый временный файл и указать путь только к этому файлу. Это может поддерживаться по прямым путям, так что если у пользователя есть простой путь, он может быть предоставлен без промежуточного файла. Но это не кажется хорошим - нужно создавать дополнительные файлы и заботиться о них, не говоря уже о необходимости дополнительной реализации. (С другой стороны, это может быть спасением для случаев, когда количество файлов в качестве аргументов начинает вызывать проблемы с длиной командной строки…)

В конце позвольте мне еще раз напомнить вам, что трюки find+ xargs(и другие) не будут работать в моем случае. Для простоты описания я показываю только один аргумент. Но мой настоящий случай выглядит примерно так:

$ ABC_FILES=$(find -L some/dir -name \*.abc | sort)
$ XYZ_FILES=$(find -L other/dir -name \*.xyz | sort)
$ ./program --abc-files $ABC_FILES --xyz-files $XYZ_FILES

Таким образом, выполнение xargsодного поиска все еще оставляет меня с тем, как иметь дело с другим ...

Используйте массивы.

Если вам не нужно обрабатывать возможность перехода на новую строку в ваших именах файлов, то вы можете сойти с рук

mapfile -t ABC_FILES < <(find -L some/dir -name \*.abc | sort)
mapfile -t XYZ_FILES < <(find -L other/dir -name \*.xyz | sort)

тогда

./program --abc-files "${ABC_FILES[@]}" --xyz-files "${XYZ_FILES[@]}"

Если делать нужно обрабатывать переводы строк в именах файлов, и имеет Баш> = 4,4, вы можете использовать -print0и -d ''в нуль-прекратить имена во время строительства массива:

mapfile -td '' ABC_FILES < <(find -L some/dir -name \*.abc -print0 | sort -z)

(и аналогично для XYZ_FILES). Если у вас нет более новой версии bash, вы можете использовать цикл чтения с нулевым символом в конце для добавления имен файлов в массивы, например

ABC_FILES=()
while IFS= read -rd '' f; do ABC_FILES+=( "$f" ); done < <(find -L some/dir -name \*.abc -print0 | sort -z)

Вы можете использовать IFS = newline (при условии, что в именах файлов нет новой строки), но вы должны установить его во внешней оболочке ДО замены:

$ ls -1
a file with spaces
able
alpha
baker
boo hoo hoo
bravo
$ # note semicolon here; it's not enough to be in the environment passed
$ # to printf, it must be in the environment OF THE SHELL WHILE PARSING
$ IFS=$'\n'; printf '%s\n' --afiles $(find . -name 'a*') --bfiles $(find . -name 'b*')
--afiles
./able
./a file with spaces
./alpha
--bfiles
./bravo
./boo hoo hoo
./baker

С, zshно не bashвы можете использовать ноль, $'\0'а также. Даже внутри bashвы можете обрабатывать перевод строки, если есть один достаточно странный символ, который никогда не используется как

 IFS=$'\1'; ... $(find ... -print0 | tr '\0' '\1') ...

Однако этот подход не обрабатывает дополнительный запрос, который вы сделали в комментариях к ответу @ steeldriver, чтобы опустить --afiles, если find пуст.

Я не уверен, что понимаю, почему ты отказался xargs.

Таким образом, выполнение xargsодного поиска все еще оставляет меня с тем, как иметь дело с другим ...

Строка --xyz-filesявляется лишь одним из многих аргументов, и нет причин считать ее особенной, прежде чем она будет интерпретирована вашей программой. Я думаю, что вы можете пройти через xargsоба findрезультата:

{ find -L some/dir -name \*.abc -print0 | sort -z; echo -ne "--xyz-files\0"; find -L other/dir -name \*.xyz -print0 | sort -z; } | xargs -0 ./program --abc-files