Por que o find não está aceitando '-exec cp {} dir +'?

3

Eu tenho um diretório, dir1 , que contém muitos arquivos cujos nomes terminam em .jpg ou .png . Quero copiar todos os arquivos .png para dir2 , que está vazio.

Este comando funciona:

find dir1 -name '*.png' -exec cp {} dir2 \;

mas este comando não:

find dir1 -name '*.png' -exec cp {} dir2 +
find: missing argument to '-exec'

Eu também tentei:

find dir1 -name '*.png' -exec cp {} -t dir2 +
find: missing argument to '-exec'

e:

find dir1 -name '*.png' -exec cp {} dir2 \+
find: missing argument to '-exec'

Depois de analisar esta página , Eu até tentei:

find dir1 -name '*.png' -exec cp {} dir2 {} +
find: Only one instance of {} is supported with -exec ... +

Esta página diz que:

-exec {} + was added in [version] 4.2.12 in 2005

Minha versão de find é 4.4.2.

O que estou fazendo de errado?

    
por EmmaV 11.09.2015 / 04:16

2 respostas

4

Graças a 'steeldriver', descobri que a resposta é porque a especificação POSIX proíbe qualquer coisa de estar entre {} e + após -exec .

    
por 11.09.2015 / 04:58
2

Existe, evidentemente, uma solução compatível com POSIX para o problema:

find dir1 -name '*.png' -exec sh -c 'cp "$@" dir2' null {} +

Não há necessidade de usar recursos não específicos do fornecedor.

BTW: AFAIK, o recurso execplus foi introduzido em 1989 por David Korn enquanto trabalhava para o SVr4. Uma informação básica importante é: POSIX não define novos recursos, mas apenas padroniza as soluções existentes, portanto, se o padrão POSIX está em conflito com a solução que era o mestre, o POSIX está geralmente errado.

Há um exemplo recente proeminente: waitid () também foi introduzido pelo SVr4 em 1989 e define que todos os 32 bits do código de saída devem ser disponibilizados para o pai. O padrão SUSv2 (de 1997) estava correto, mas por razões desconhecidas, versões posteriores mencionaram que o código de saída deve ser mascarado por 0xFF. Isso foi identificado recentemente como sendo um bug POSIX.

    
por 11.09.2015 / 09:54

Tags