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. :)
-
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 $* fiMax Howell : Great :) Thanks. Although not quite perfect as it doesn't handle: $ find Which should get converted to: $ find ./ -
This is probably not what you want but how about:
alias find="find ."or choose a new name (
findlfor find local?)Greg Hewgill : 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.ΤΖΩΤΖΙΟΥ : It would search the local directory AND the path you specify. find is not restricted to one path argument.Max Howell : Although if I specify a path, I probably don't want it searching the current directory as well.James Fassett : 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. -
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
shscripts instead of relying onbashwhich might not be installed everywhere.Max Howell : 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.dmckee : For this same reason I have gotten into the habit of using the "-print" action even on find that assume it. -
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=findwithout 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.Max Howell : 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.ΤΖΩΤΖΙΟΥ : What you are saying is obvious. Note that nobody forces you to assume "." as a default target for find, except yourself (check your question!).Max Howell : No matter how many ways I look at it, I don't understand your point.ΤΖΩΤΖΙΟΥ : It's not important, since you really needed a script, which Jonathan Leffler provided and is indeed the best answer. -
If you can't discipline yourself to use
find'correctly', then why not install GNUfind(fromfindutils) in a directory on your PATH ahead of the systemfindcommand.I used to have my own private variant of
cpthat would copy files to the current directory if the last item in the list was not a directory. I kept that in my personalbindirectory 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 thatcp file1 file2is 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 -- . "$@" exec /usr/bin/find "$@"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' -printbecause 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
cpcommand.Max Howell : I accepted this as it fits my needs best, many thanks.
0 comments:
Post a Comment