I am using Gnuwin32 binaries on a Windows environment.
When I want to find files of a certain type, let's say PDF, I usually run:
find . -iname '*.pdf' -print
This works perfectly on any UNIX system.
find.exe . -iname "*.pdf" -print
But under Windows, having replaced single quotes with double-quotes, it only works when there is no pdf file in the current directory, otherwise the *
gets expanded.
Worse: when there is exactly one PDF file in the current directory, it will expand, there will be no syntax error and you will get wrong results.
I have tried escaping the *
with a caret, a backslash, a star itself, putting inside double quotes: nothing works for me.
Real example:
Okay, here are all my files:
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
Good behaviour, wildcard was not expanded
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
Caution, inconsistent behaviour, wildcard was expanded:
C:\tmp\a>find . -iname "*.pdf"
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
C:tmp\a>cd ..\b
Caution, inconsistent behaviour, wildcard was expanded :
C:\tmp\b>find . -iname "*.pdf"
./1.pdf
./bb/1.pdf
Thank you
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.
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'.
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, butfind.exe . -name 'GameCli*'
doesn't work.MinGW's
find.exe . -name 'GameCli*'
work.
I haven't found anything better than just avoiding wildcard characters
find.exe . -iregex ".+\.pdf" -print
@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.
来源:https://stackoverflow.com/questions/3995493/gnuwin32-find-exe-expands-wildcard-before-performing-search