#6 'find . -name' has inconsistent behavior

[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.

[GnuWin]

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.

[Jarek Czekalski]

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.

[Jim Michaels]

I also get this problem. here is the result:

    d:\www\jimm>findd . -name "*.html" -exec grep "jquery\-1\.7\.2\.js" {} ; -print
    findd: paths must precede expression
    Usage: findd [-H] [-L] [-P] [path...] [expression]

    d:\www\jimm>which findd
    D:\gnuwin32\GetGnuWin32\gnuwin32\bin\findd.EXE

    d:\www\jimm>

I renamed find.exe to findd.exe because of the windows find.exe command in %windir%\system32 has the same name as gnuwin32's find.exe
so this is definitely not an issue. it seems like it was working for a while, then it stopped working. It could have something to do with a windows update maybe?
I also updated my grep and findutils from here, and now I am on a 64-bit machine. on the 32-bit machine I had no problems I could remember, except that grep ignores most regexes.