I thought I would make a note of this in case there are other people having similar issues.
After trying to do a recursive dos2unix call, as detailed in the following blog post: http://cyberzen.wordpress.com/2006/07/15/recursive-dos2unix/
I came across the ‘find: paths must precede expression’ error like mentioned in the comments. A google search and look through the help text gave no answers, so I had a play around with calling find different ways. It seems
find . -name *.*
throws a ‘find: paths must precede expression’, while simply enclosing the wildcard in single quotes makes it work! e.g.
find . -name ‘*.*’
Such a simple solution, you would think it would be a lot easier to find a mention of it…
Anyway, I hope this post helps someone out!!!
Advertisements
Tahnks for posting
Glad I could help!
Thank you for this. Much appreciated!
I’ve used Linux professionally for nearly ten years and never came across this. It was driving me nuts. Thanks!
No problem mate 🙂 Just glad to help!
Very helpful. Thanks
Thanks. Solved my problem too.
Now it would be nice to know why the
#%)*#^ quotes are necessary.
I too didn’t understand the problem until I read the solution. The problem is when the * gets expanded. Try this:
$ mkdir one_file
$ cd one_file
$ touch one
$ find -name *
./one
$ touch two
$ find -name *
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path…] [expression]
The problem is that find has only one positional argument, the path, which comes before all commands. When the unquoted * expands more than one file name, only the first is matched to the -name command, the others are assumed to be positional arguments, i.e. paths, and they are in the wrong place. That is awful error feedback, but it is consistent unix behavior.
OMG thank you!!
Thanks!
Thanks, that was useful.
Awesome! worked for me. I’m surprised this isn’t as intuitive of a fix. What does the quotes have to do with preceding expressions.. ?
Thanks a tonne!
sriram@sriram-desktop:~/Desktop$ find /home/sriram -name *.jpg -exec ls {} \;
find: paths must precede expression: snapshot1.jpg
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path…] [expression]
sriram@sriram-desktop:~/Desktop$ find /home/sriram -name ‘*.jpg’ -exec ls {} \;
/home/sriram/Downloads/r001-004.jpg
/home/sriram/Downloads/r001-078.jpg
/home/sriram/Downloads/archive/background-fedora-animated/fedora8/day.jpg
/home/sriram/Downloads/archive/background-fedora-animated/fedora8/sunset.jpg
^C
thanks
to use GNU VERSION OF FIND on windows —
find . -iname “*.txt”
will work
This has certainly helped me out. Thank you!
Brilliant! Solved it for me =)
thanks man.. you saved me a lot of time . I am going to play tennis thanks to you!!!
call me dumbo but the solution helped me quick.. and me think about basics …
Thanks for the quick tips. This issue has been puzzled me for a while and now you find me a solution!
Thanks, solved my problem
helped me a lot!!!
Thanks it worked!
Thank you. This has driven me nuts for years. The wildcard expansion makes a lot of sense – which also explains the apparent random behavior – where sometimes you’d get results, sometimes none and sometimes less results than you know exist – depends on what (if anything or multiples) in the current directory matches!
Nice post. I see you posted this in July of ’08. And it’s still helping people out. Fantastic, seriously. I fought with this for about 3 minutes, googled the error, and came here and minute later all was good again. Thanks tons.
I understand the shell interpretation & the following works as expected:
$ find . -type f -name “*.out” -print
./null.out
find: ./vmware-root: Permission denied
find: ./lost+found: Permission denied
What am I missing when I want a redirection of the error output???
$ find . -type f -name “.out” -print 2>/dev/null
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path…] [expression]
thanks
find . -name p*log
./plm/plm.log
./plm/plm2.log
find . -name *log
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path…] [expression]
So there is something more subtle is going on here…
Awesome fix! Thanks for blogging it!
Thanks! This just saved me from a lot of hair-pulling.
Thanks, this helped me out!
Oh, glad I have found it. Thanks!