[David Wang]

Hello,

I've encountered an odd case where the 'find' command does not work like its linux counterpart. I'm using "find.exe" distributed in the FindUtils package, version 4.2.20, installed by using the setup program "Complete package, except sources". Testing on Windows 7 x64 (the only Windows platform I've tested it on), 'find' works great, except in the following command variations:
find . -iname
find . -name
find . -iname ""
find . -name ""
When these commands are used, I get the error message:
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

However, these similar commands DO work in Windows:
find . -iname .
find . -name .
find . -iname "."
find . -name "."
And, so do these
find .
find . ""

And, ALL of the above commands work on the two linux variants I tested on, Fedora and openSuse, by using the native 'find' command.
Is this a bug, or is there a good reason for this discrepancy that I don't understand? Thanks!

Note: I realize this use case is a little odd in that no one would realistically type this command. However, I discovered this problem when using emacs. Emacs generates a much longer command, as part of its grep functionality, but I distilled the problem into the above commands.

• David W.

Most likley, this has something to do with the fact that the Windows command shell (cmd.exe) expands the wildcards before passing it on to the find command.

I am familiar with this message. My experience says that it happens when the file to search for (or maybe more such files) is contained in current directory. So going up a directory may help. Other workaround is to use -regex instead. So a failing command:

find . -name a*

may be substituted with

• find this_dir -name a* (from parent directory)
• find . -regex .*/a[a-z0-9.A-Z_]*

Unfortunately this may help only in manually issed commands.

I am also not sure whether Windows is to be blamed for this misbehaviour. I checked with a testing app and arguments are passed without a change. For example such args:

• . -name b*
• . -name "b*"

Probably the expansion is really done at some place and somehow it is not prevented by quotes.