views:

1065

answers:

5

I am a heavy command line user and use the find command extensively in my build system scripts. However on Mac OS X when I am not concentrating I often get output like this:

$ find -name \*.plist
find: illegal option -- n
find: illegal option -- a
find: illegal option -- m
find: illegal option -- e
find: *.plist: No such file or directory

Basically, I forgot to add the little dot:

$ find . -name \*.plist

Because BSD find requires the path and GNU find doesn't (it assumes the current directory if you don't specify one). I use Linux, Mac OS X and Cygwin often all at the same time, so it's of great benefit to me to have all my tools behave the same. I tried writing a bash find function that added "./" if I forgot, but I failed. Thanks for your help. :)

+3  A: 
find ./ -name "*.plist"

edit: hmm, i may have misunderstood the question! if you were crazy, how about emulating it via a shell script? i routinely keep random utility scripts in ~/.bin, and that's the first thing in my PATH. if you had a similar setup perhaps you could do something like: (untested!)

#!/bin/sh
# remapping find!
CMD=`echo $1 | cut -c 1`
if [ $CMD = '-' ]
then
# pwd search
  /usr/bin/find ./ $*
else
# regular find
  /usr/bin/find $*
fi
Owen
Great :) Thanks. Although not quite perfect as it doesn't handle:$ findWhich should get converted to:$ find ./
Max Howell
+1  A: 

This is probably not what you want but how about: alias find="find ."

or choose a new name (findl for find local?)

James Fassett
I was about to suggest an alias but then realised that it wouldn't work to well if you *wanted* to specify a path on the find command line.
Greg Hewgill
It would search the local directory AND the path you specify. find is not restricted to one path argument.
ΤΖΩΤΖΙΟΥ
Although if I specify a path, I probably don't want it searching the current directory as well.
Max Howell
That is why I prefixed the solution with: This is probably not what you want. I still think you should bind this custom functionality to a custom command (e.g. findl) so that you can use the OS X behaviour when you want.
James Fassett
+2  A: 

I would suggest that if you're writing scripts (which are more likely to be migrated from one system to another sometime in the future) that you should try to use the more specific form of the command, that is specifying the "." instead of relying on a default. For the same reason, I might even suggest writing sh scripts instead of relying on bash which might not be installed everywhere.

Greg Hewgill
This is a good point. Really I should add a script/function on the other platforms that bails out the find command if I don't specify the path. That way I wont start writing scripts that may break for different implementations of various tools.
Max Howell
For this same reason I have gotten into the habit of using the "-print" action even on find that assume it.
dmckee
+4  A: 

If you must call it 'find', then you want:

alias find=/usr/bin/find\ .

in your .profile or .bash_profile or …. Substitute the real path (if not /usr/bin/find) on your Mac OSX. Enter the full path to avoid cycles (bash normally would interpret alias find=find without issues, but better be sure).

But you better not name the alias find (findl, myfind etc), because it will become a habit and trouble for you if you try it on another system.

ΤΖΩΤΖΙΟΥ
I never even tried this since I didn't think find could take multiple paths and thus figured I wouldn't be able to search paths other than the current one. Many thanks :)
Max Howell
Actually this is no good. Since if I specify a path, I'm unlikely to want to include the current directory too.
Max Howell
What you are saying is obvious. Note that nobody forces you to assume "." as a default target for find, except yourself (check your question!).
ΤΖΩΤΖΙΟΥ
No matter how many ways I look at it, I don't understand your point.
Max Howell
It's not important, since you really needed a script, which Jonathan Leffler provided and is indeed the best answer.
ΤΖΩΤΖΙΟΥ
+2  A: 

If you can't discipline yourself to use find 'correctly', then why not install GNU find (from findutils) in a directory on your PATH ahead of the system find command.

I used to have my own private variant of cp that would copy files to the current directory if the last item in the list was not a directory. I kept that in my personal bin directory for many years - but eventually removed it because I no longer used the functionality. (My 'cp.sh' was written in 1987 and edited twice, in 1990 and 1997, as part of changes to version control system notations. I think I removed it around 1998. The primary problem with the script is that cp file1 file2 is ambiguous between copying a file over another and copying two files to the current directory.)

Consider writing your own wrapper to find:

#!/bin/sh
[ ! -d "$1" ] && set -- . "[email protected]"
exec /usr/bin/find "[email protected]"

The second line says "if argument 1 is not a directory, then adjust the command line arguments to include dot ahead of the rest of the command. That will be confusing if you ever type:

~/bin/find /non-existent/directory -name '*.plist' -print

because the non-existent directory isn't a directory and the script will add dot to the command line -- the sort of reason that I stopped using my private cp command.

Jonathan Leffler
I accepted this as it fits my needs best, many thanks.
Max Howell