The examples you gave, all work fine on my system (MS-Windows XP SP2). For example,
find . -iname "*n*"
lists all the files in the current directory and below with an n in their name.
So you'll have to give a more specific example before this can be investigated further.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I've seen the same thing. It looks like the gnuwin32 find 4.2.20 (my version) is expanding the wildcard using matches in the current directory. That gives the kind of errors grumbled00k saw if there is more than one match. So with a file structure like this
./foofoo
./Child/foofoo
./Child/foobar
Running find . -iname 'foo*' from . returns only the first two files
Running from ./Child gives the "Paths must precede expression" error
Running from .. returns all three files
This looks like a bug. It is a difference in behavior compared to GNU find 4.1.7 on linux and the cygwin version of GNU find 4.2.11 (which always return all three files)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Same problem here, gnuwin32 find version 4.2.20. The problem (expanding the
wildcard using matches in the current dir, resulting in "Paths must precede
expression" error) manifests itself on Windows Vista Enterprise SP1 (x86) and
Windows 7 Ultimate (x64), but not on Windows XP Prof. SP2.
That's why user gnuwin32 couldn't reproduce this on XP; you need Vista or
Windows 7.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using find for many years in the linux bash. Now I'm confused when using gnuwin32's find.exe,
e.g. this way:
>find "path" -iname "n"
or
>find "path" -iname "nnn"
or
>find "path" -iname "nbb"
work fine, but I get:
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]
when executing this:
>find "path" -iname "n"
or
>find "path" -iname "nb"
or
>find "path" -iname ".nb"
or
>find "path" -iname "*b"
What's the difference to linux find here? (a bug???)
What's the exact value of "path" in your examples?
Any path, like "." or "C:\users\user\documents".
Try searching for "nnn", "nn" or "n" in the default path (".").
Only "n" gives the error.
Still no idea? ... gnuwin's find is completely useless when it's impossible to search for files with a certain extension ...
The examples you gave, all work fine on my system (MS-Windows XP SP2). For example,
lists all the files in the current directory and below with an n in their name.
So you'll have to give a more specific example before this can be investigated further.
I think I've seen the same thing. It looks like the gnuwin32 find 4.2.20 (my version) is expanding the wildcard using matches in the current directory. That gives the kind of errors grumbled00k saw if there is more than one match. So with a file structure like this
./foofoo
./Child/foofoo
./Child/foobar
Running find . -iname 'foo*' from . returns only the first two files
Running from ./Child gives the "Paths must precede expression" error
Running from .. returns all three files
This looks like a bug. It is a difference in behavior compared to GNU find 4.1.7 on linux and the cygwin version of GNU find 4.2.11 (which always return all three files)
Same problem here, gnuwin32 find version 4.2.20. The problem (expanding the
wildcard using matches in the current dir, resulting in "Paths must precede
expression" error) manifests itself on Windows Vista Enterprise SP1 (x86) and
Windows 7 Ultimate (x64), but not on Windows XP Prof. SP2.
That's why user gnuwin32 couldn't reproduce this on XP; you need Vista or
Windows 7.
I confirmed this bug on my Win 7 x64 machine.
Here is another example:
http://stackoverflow.com/questions/3995493/gnuwin32-find-exe-expands-
wildcard-before-performing-
search
I hope this bug can be fixed ASAP, as "find" is very popular.