Gnuwin32 find.exe erweitert Wildcard vor Suche durchführen

Question

Ich bin mit GnuWin32 Binärdateien auf einer Windows-Umgebung.
Wenn ich Dateien eines bestimmten Typs finden mag, lassen Sie sich PDF sagen, dass ich in der Regel laufen:

find . -iname '*.pdf' -print

Das funktioniert perfekt auf jedem UNIX-System.

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

Aber unter Windows, einfachen Anführungszeichen mit doppelten Anführungszeichen ersetzt zu haben, es funktioniert nur, wenn es keine pdf-Datei im aktuellen Verzeichnis ist, sonst wird die * erweitert wird .

Schlimmer noch:., Wenn es genau eine PDF-Datei im aktuellen Verzeichnis ist, wird es erweitern, wird es keine Syntaxfehler und Sie werden falsche Ergebnisse erhalten

Ich habe versucht, die * mit einem caret entkommen, einen Schrägstrich, ein Stern selbst, in doppelte Anführungszeichen setzen. Nichts funktioniert für mich

Reales Beispiel:

Okay, hier sind alle meine Dateien:

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

Gutes Verhalten wurde Wildcard nicht erweitert

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

Achtung, inkonsistentes Verhalten, Wildcard wurde erweitert:

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

C:tmp\a>cd ..\b

Achtung, inkonsistentes Verhalten, Wildcard wurde erweitert:

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

Danke

Answer 1

I have found myself the solution to my problem.

• Gnuwin32's find.exe is not working on recent Windows Versions (Vista, Seven) because it expands wildcards matching only the contents of the current directory.
• Similarly, an old version of find.exe from UnxUtils suffered the same bug.
• The latest find.exe from UnxUtils is working.

Answer 2

One workaround is to add a wildcard/expansion that the Windows shell does not expand, but GNU find does:

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

The Windows shell[*] does not interpret/expand square braces. In addition, colon is not a valid character in Windows filenames, so this pattern cannot match any Windows filename, and the Windows shell will always pass the pattern through to find.exe.

Find.exe will then find any files ending in .pdf or :pdf , but since no files can have a name ending in :pdf under Windows, it will only find files ending in .pdf.

[*] It's actually the C runtime that does/not perform these wildcard expansions. I don't understand the Win32 C runtime well enough to refine the distinction, so for now for the purpose of this workaround, I'm just saying 'shell'.

Answer 3

I suffered this problem this afternoon. Benoit's UnxUtils can work. I also find MinGW's find.exe can work,it is under my

"MinGW\msys\1.0\bin"

directory. And it is consistent with the manual.

gnuwin32 and UnxUtils: find.exe . -name GameCli* work, but find.exe . -name 'GameCli*' doesn't work.

MinGW's find.exe . -name 'GameCli*' work.

Answer 4

I haven't found anything better than just avoiding wildcard characters

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

Answer 5

@OP, i have consistent behaviour

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

You may want to try to use findutils instead of UnxUtils.