GnuWin32 find.exe wildcard avant d'effectuer agrandit la recherche

Question

J'utilise les binaires GnuWin32 sur un environnement Windows.
Quand je veux trouver les fichiers d'un certain type, disons que PDF, je habituellement courir:

find . -iname '*.pdf' -print

Cela fonctionne parfaitement sur tous les systèmes UNIX.

find.exe . -iname "*.pdf" -print

Mais sous Windows, ayant des guillemets simples remplacé par des guillemets doubles, il ne fonctionne que quand il n'y a pas de fichier pdf dans le répertoire courant, sinon le * s'étendu .

Pire encore:. Quand il y a exactement un fichier PDF dans le répertoire courant, il élargira, il n'y aura pas d'erreur de syntaxe et vous obtiendrez des résultats erronés

J'ai essayé d'échapper à la * avec un caret, une barre oblique inverse, une étoile elle-même, mettre à l'intérieur des guillemets doubles. Rien ne fonctionne pour moi

Exemple réel:

D'accord, voici tous mes fichiers:

C:\tmp>find . -type f
./a/1.pdf
./a/2.pdf
./a/aa/1.pdf
./b/1.pdf
./b/bb/1.pdf
./b/bb/2.pdf

Le bon comportement, n'a pas été étendu wildcard

C:\tmp>find . -iname "*.pdf"
./a/1.pdf
./a/2.pdf
./a/aa/1.pdf
./b/1.pdf
./b/bb/1.pdf
./b/bb/2.pdf

C:\tmp>cd a

Attention, un comportement incohérent, générique a été élargi:

C:\tmp\a>find . -iname "*.pdf"
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

C:tmp\a>cd ..\b

Attention, un comportement incohérent, générique a été élargi:

C:\tmp\b>find . -iname "*.pdf"
./1.pdf
./bb/1.pdf

Merci

Answer 1

Je me suis trouvé la solution à mon problème.

• Le find.exe de GnuWin32 ne fonctionne pas sur les versions récentes de Windows (Vista, Seven), car il étend les jokers correspondant seulement le contenu du répertoire en cours.
• De même, une ancienne version de find.exe de UnxUtils a subi le même bug.
• La dernière find.exe de UnxUtils fonctionne.

Answer 2

Une solution consiste à ajouter un caractère générique / extension que le shell Windows ne se développe pas, mais vous pouvez trouver GNU ne:

find.exe . -name *[.:]pdf -print

Le shell Windows [*] n'interprète pas / développer des crochets. En outre, du côlon est pas un caractère valide dans les noms de fichiers Windows, donc ce modèle ne peut pas correspondre un nom de fichier Windows et le shell Windows passera toujours le modèle jusqu'à find.exe.

Find.exe alors trouver tous les fichiers se terminant par .pdf ou :pdf, mais puisque aucun fichier peut avoir un nom se terminant par :pdf sous Windows, il trouvera que les fichiers se terminant par .pdf.

[*] Il est en fait le moteur d'exécution C qui ne / pas effectuer ces extensions génériques. Je ne comprends pas suffisamment d'exécution Win32 C bien pour affiner la distinction, donc pour l'instant dans le but de cette solution de contournement, je dis juste « shell ».

Answer 3

Je souffrais de ce problème cet après-midi. Les UnxUtils de Benoit peuvent travailler. Je trouve aussi find.exe peut le travail de MinGW, il est sous mon

  

"MinGW \ msys \ 1.0 \ bin"

répertoire

. Et il est compatible avec le manuel.

  

GnuWin32 et UnxUtils: Travaux de find.exe . -name GameCli*, mais   find.exe . -name 'GameCli*' ne fonctionne pas.

     

Les travaux de find.exe . -name 'GameCli*' de MinGW.

Answer 4

Je n'ai trouvé rien de mieux que de simplement éviter les caractères génériques

find.exe . -iregex ".+\.pdf" -print

Answer 5

@OP, j'ai un comportement cohérent

C:\test\temp>find . -iname "*.txt"
./1.txt
./2.txt

C:\test\temp>cd a

C:\test\temp\a>find . -iname "*.txt"

C:\test\temp\a>cd ..\b

C:\test\temp\b>find . -iname "*.txt"

C:\test\temp\b>find --version
GNU find version 4.2.20
Features enabled: CACHE_IDS D_TYPE

Vous pouvez essayer d'utiliser findutils au lieu de UnxUtils.