Primeiro, para eliminar respostas triviais, mas inaplicáveis: não posso usar o truque find+ xargsnem suas variantes (como findem -exec) porque preciso usar poucas expressões desse tipo por chamada. Voltarei a isso no final.

Agora, para um exemplo melhor, vamos considerar:

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

Como passo esses argumentos para program?

Apenas fazê-lo não faz o truque

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

falha desde que programobtém os seguintes argumentos:

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

Como pode ser visto, o caminho com espaço foi dividido e programconsidera dois argumentos diferentes.

Cite até que funcione

Parece que usuários iniciantes como eu, quando enfrentamos esses problemas, tendem a adicionar aspas aleatoriamente até que finalmente funcione - só que aqui não parece ajudar…

"$(…)"

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

Como as aspas impedem a divisão de palavras, todos os arquivos são passados ​​como um único argumento.

Citando caminhos individuais

Uma abordagem promissora:

$ ./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"

As citações estão aí, com certeza. Mas eles não são mais interpretados. Eles são apenas parte das cordas. Portanto, não apenas eles não impediram a divisão de palavras, mas também entraram em discussões!

Alterar IFS

Então eu tentei brincar com IFS. Eu preferiria findcom -print0e sortcom -zqualquer maneira - para que eles não tenham problemas nos "caminhos com fio". Então, por que não forçar a divisão de palavras no nullpersonagem e ter tudo?

$ ./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

Portanto, ele ainda se divide no espaço e não se divide no null.

Tentei colocar a IFStarefa tanto em $(…)(como mostrado acima) quanto antes ./program. Também eu tentei outra sintaxe como \0, \x0, \x00ambos citados com 'e ", assim como com e sem o $. Nenhum deles parecia fazer diferença ...

E aqui estou sem idéias. Tentei mais algumas coisas, mas tudo parecia ter os mesmos problemas listados.

O que mais eu poderia fazer? É factível?

Claro, eu poderia programaceitar os padrões e fazer pesquisas em si. Mas é muito trabalho duplo, enquanto corrige-o para uma sintaxe específica. (Que tal fornecer arquivos com um greppor exemplo?).

Também eu poderia fazer o programaceitar um arquivo com uma lista de caminhos. Em seguida, posso despejar facilmente a findexpressão em algum arquivo temporário e fornecer o caminho apenas para esse arquivo. Isso pode ser suportado em caminhos diretos, para que, se o usuário tiver apenas um caminho simples, ele possa ser fornecido sem arquivo intermediário. Mas isso não parece bom - é preciso criar arquivos extras e cuidar deles, sem mencionar a implementação extra necessária. (No lado positivo, no entanto, pode ser um resgate para os casos em que o número de arquivos como argumentos começa a causar problemas com o comprimento da linha de comando ...)

No final, gostaria de lembrá-lo novamente que find+ xargs(e similares) truques não funcionarão no meu caso. Para simplificar a descrição, estou mostrando apenas um argumento. Mas meu caso verdadeiro se parece mais com isso:

$ 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

Fazer xargsuma pesquisa a partir de uma ainda me deixa com como lidar com a outra…

Use matrizes.

Se você não precisar lidar com a possibilidade de novas linhas nos seus nomes de arquivos, poderá se safar

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

então

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

Se você fazer necessidade de novas linhas punho dentro de nomes de arquivos, e têm o bash> = 4.4, você pode usar -print0e -d ''como nulo-terminar os nomes durante a construção array:

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

(e da mesma forma para XYZ_FILES). Se você não tiver o bash mais recente, poderá usar um loop de leitura com terminação nula para anexar nomes de arquivos às matrizes, por exemplo

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

Você pode usar IFS = newline (assumindo que nenhum nome de arquivo contenha nova linha), mas você deve configurá-lo no shell externo ANTES da substituição:

$ 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

Com zshmas não bashvocê pode usar nulo $'\0'também. Mesmo em bashvocê , você pode lidar com nova linha se houver um personagem suficientemente estranho que nunca seja usado como

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

No entanto, essa abordagem não trata da solicitação adicional que você fez nos comentários na resposta do @ steeldriver para omitir os --afiles se encontrar um estiver vazio.

Não sei se entendi por que você desistiu xargs.

Fazer xargsuma pesquisa a partir de uma ainda me deixa com como lidar com a outra…

A string --xyz-filesé apenas um dos muitos argumentos e não há motivo para considerá-la especial antes de ser interpretada pelo seu programa. Eu acho que você pode passar xargsentre os dois findresultados:

{ 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