“Don’t you just hate it when you can’t find a file you need, but you know it’s on your computer? Wouldn’t you like an easy way to track down files anywhere on your computer? If so, I have good news for you, a command available to you at the friendly Linux CLI called find.”
Like it was stated in the article, I find locate a lot better. Did that make any sense?
Hmm, locate > find
dam
locate is nice, but it often isn’t current. Locate simply searches a database of the filesystem which is only as good as how often the database is rebuilt, whereas find searches the actual filesystem. So both tools have their uses, but find tends to be more current (though much slower.)
Just my $0.02.
There are implementations of locate that update the database in real time as files are altered:
http://rlocate.sourceforge.net
http://fsdb.sourceforge.net
I don’t know if locate is better than find or not, but I always use locate after doing a updatedb. The only reason I do this is because I did not know about the find command.
So usually it looks like this for me:
updatedb
locate alsa
If you want to search the whole file tree, and only want to use a path/file name as search criteria, updatedb + locate probably is the best choice. This is because both will have to read the whole disk the first time, but if you end up searching more than once locate will be alot faster in the end.
If you just want to search inside for instance a source code tree, and/or need to do more advanced searches (file type, time of access/creation, etc) then find is better.
I preffer the locate command because there is only a negligible delay before you have all your results. It’s no spotlight like in OS X, but it’s reasonable enough. The only downside is that you should set up a cron job to run every night for the updatedb command so the database doesn’t end up more than 24 hours outdated. Find can find files without having to worry about a slightly old database, but it also takes much longer.
I’m looking forward to when spotlight-like functionality is well implemented into Linux, although I’m not as keen to drop the use of folders. IMO searches are supposed to compliment folders, not replace them. I’m sure beagle will prove interesting, I also heard that some sort of similar seach feature was planned for KDE 4, perhaps based off beagle but I really don’t know.
I tried some of the more advanced search programs for Windows just to be very disappointed, if the software wasn’t bad the absense of file type support was.
I’m looking forward to when spotlight-like functionality is well implemented into Linux, although I’m not as keen to drop the use of folders. IMO searches are supposed to compliment folders, not replace them. I’m sure beagle will prove interesting, I also heard that some sort of similar seach feature was planned for KDE 4, perhaps based off beagle but I really don’t know.
If you are using KDE, check out kio-locate. It adds a locate kioslave that allows you to type in locate:file and have your matches come up in konqueror organized by folders etc. Where I find it cooler is the ability to use it in any standard KDE file picker. If you’re trying to open a file and can’t remember the full name or location, just enter locate:file for a filename and then select the file from the search results.
Ok, so it’s not beagle or spotlight, but it is pretty useful if you do rely on locate a lot (I do myself), and it is integrated into KDE. It uses locate as the backend so all the same weaknesses apply, but it’s better than nothing.
Cheers.
Beagle works for me.
Are there a lot of web surfers geek enough to visit osnews.com and newbie enough not to know the “find” command?
I mean, I like tips and this one explains clearly what the find command does, but I think that 20 minutes after I first played with UNIX in my life (in 1998), I knew what the “find” command was and how to use it.
Locate is indeed much faster (but with less options).
If you want to do a basic search like “locate” does and want it to be faster than a “find” on a system where “locate” is not installed, use:
du -a /search/path | grep keyword
Where “/search/path” is the root path where you want to start the search and “keyword” is the file you are looking for.
Tom
Are there a lot of web surfers geek enough to visit osnews.com and newbie enough not to know the “find” command?
Yep, I’m one of those
I never needed to use a search command in DOS, from there I had Win98 with a nice GUI to search files, then came XP with the dog, and finally, by the time I started using Linux there were GUIs for find in gnome and KDE. I tried Beagle and just didn’t liked it
If you want to do a basic search like “locate” does and want it to be faster than a “find” on a system where “locate” is not installed, use:
du -a /search/path | grep keyword
I highly doubt that this any faster than using
find /search/path -name “*keyword*”
or even
find /search/path | grep keyword
In fact I’m not even in doubt and call BS right away…
find actually does a lot more than just searching. For example, it can also be used as a tool to track SUID executables, set all maps and executables to 755 and the rest to 644, and so on. Find is actually much more advanced than locate, but in my opinion it should not be used as a dumb search tool.
I use find to search for files all the time, or rather, I use find to feed information to grep so I can use it to find what I’m looking for.
For example: find | grep -i ‘*.mp3’
Why not use find’s own options to find the type of file?
to use your example: find ./ -iname “*.mp3”
Thanks for the “-iname”! Can’t tell you how many times I’ve typed “*[mM][pP]3”
That seems a bit extreme…
“…Wouldn’t you like an easy way to track down files anywhere on your computer? If so, I have good news for you…”
I just saved a bunch of money on my car insurance by switching to Geico.
Sorry, but I couldn’t resist.
On a related note to locate:
locate is nice yes, but it’s lack of flexibility I think makes mostly suited for a CLI interactive use where as find’s plethora of options makes it a fantastic tool to use in scripts. Often, in fact, the entire desired operations can be done with a carefully structured find command by utilizing it’s -exec option.
I don’t plan on giving up my find for locate anytime soon.
Edited 2005-10-31 18:04
There is a search tool similar to Beagle for KDE: Kat (http://kat.mandriva.com/).
Bah, find is even better than that. Typically I use find to find a string (usually a function definition) in a set of files, e.g.
grep “someFunction” `find /src/tree/is/here`
If you use a decent shell like zsh or eshell, find becomes almost unnecessary. Your example would turn into something like: grep “someFunction” /src/tree/is/here/**/*.cc
why not just do ‘grep -r “someFunction” /src/tree/is/here’ ?
$ man find
I’m expecting the new inotify-feature of the 2.6 kernel to be
used to get real-time find/locate database update pretty soon.
Fast search, always up-to-date database, no nightly jamming of
the machine.
Also, using existing efficient SQL engine such as PostgreSQL or
MySQL could maybe speed-up the searches, decrease the
required programming effort and other meta-data
from the files (linecount, wordcount, pagecount, width, height,
playtime, quality, md5sum, format, etc. etc.) could be included.
I hardly ever use “find” nowadays – it’s *only* good for finding files you’ve just put on the system (in which case you know where they are!). For all other cases, as long as the “updatedb” command is cron’ed on your system, you can search a snapshot from overnight with something like “slocate mp3”.
Sadly, I suspect a lot of people have been complaining in Fedora Core about anacron kicking in 65 minutes after a “first reboot of the day” and running /etc/cron.daily/slocate.cron (which causes a fair chunk of I/O for a couple of minutes). This moaning has led to Fedora Core 4 shipping with the updatedb cron job disabled by default, which is a tragedy really, because then people like Joe Barr would never discover it (slocate won’t work if updatedb has never been run).
Oh, to re-enable it in FC4, set DAILY_UPDATE=yes in /etc/updatedb.conf – it’s the first thing I did after FC4 was installed…
Not available under Linux, tho… 🙁
Tomorrow on osnews, we’ll talk about the wonders of “ls” and “grep” and if we show enough interest, maybe they’ll cover “info” and “man” too!
catching up with Norton Utilities?
catching up with Norton Utilities?
Peter Norton was still crapping his pants when find and locate were first developed… 😀
I´d also like to say thanks for the useful arguments given on the article like -o, -iname and others. I lost the count of how many regexps I´ve made in order to accomplish the same results. 😛
However, associate grep with find sometimes might be a bit of a overkill, since grep needs to wait find to supply the files that it will research. It is much faster to let grep do the research by itself with the -r flag. It will scan directories recursively then.
I usually use grep with -r together with -l and pipe the result to xargs to clean up my mail queues of SPAM. -l will make grep report only the name of the file that matches the regexp instead of the usual result file:line_that_matches_regexp.
grep -rl “From: [email protected]” /var/mail/ | xargs -iXX rm -fv XX
Works like a charm!
DeadFish Man
OMG there’s a command called cat!!!!!!!!!!1111 now I get the contents of files LLOL!!!!!!!!
gnome already has this functionality in a frontend. under Ubuntu.. click places-> search for files, up pops the frontend.. enter filename or extension (.mp3) click enter. it will search home directory or filesystem or any other bookmark you have under nautilus