Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hi, it's late night, and I'm on disk searching commands with my unixacademy DVD training. It primarily discusses two search tools: locate and find.
I understand the difference between two. What I'm asking is, I don't see "locate" to be much used as "find". I read few books and most of them discuss "find", but not "locate". I also searched on forums, most questions about "find".
What I'm asking: is "locate" a general mainstream or some kind of "exotic" command?
Last edited by kienlarsen; 04-29-2011 at 03:18 AM.
Well I am not so sure about locate, but find has a lot strength due to not only all the things it can do but also the exec options make it extremely powerful.
Also, locate is not generally considered standard fare on all distros.
Hi guys, what I'been asking, is "locate" is generally accepted tool? I mean, I'm learning and IT IS ALL NEW TO ME. From my past Windows trainings I remember that various brands tend to present their own, proprietary solutions and push them for you to use. That is my only concern.
I've been experimenting a lot with "find" and I've got one question. It appears that find is really heavy on resources, at least on my laptop. I created a huge fake data and directory structure, with many thousands files just for sake of experimentation, and I run "find" against it. I also watch my system utilization with "top" is another terminal and there's clear "spike" in utilization when "find" runs.
My question is, is is always like that? Isn't it possible to index its known paths?
that's what the updatedb/locate combo is for. NB: AFAIK, it's Linux thing; ie not avail on eg Solaris, HP-UX etc.
'find' OTOH is a basic Unix cmd from way back when. When updatedb is run, it does essentially the same thing as find, but stores the results. You cannot do that with find, unless you want to write your own version of 'updatedb/locate'
Helpful thread, i didn't know the difference between the two commands.
How does whereis command differ from find and locate? Does it use updatedb? i read man page, but still don't get it 100%.
whereis locates source/binary and manuals sections for specified files.
The supplied names are first stripped of leading pathname components
and any (single) trailing extension of the form .ext, for example, .c.
Prefixes of s. resulting from use of source code control are also
dealt with. whereis then attempts to locate the desired program in a
list of standard Linux places.
'find' OTOH is a basic Unix cmd from way back when. When updatedb is run, it does essentially the same thing as find, but stores the results.
What updatedb stores is just the paths to the files....no file sizes, modification times, etc, etc. So, there is a lot of stuff that you can do with find (as an example, finding files with a modification date that falls inside a particular date range) that you just can't do with locate.
On the other hand, locate is fast. Find, particularly if you are searching over a whole file system isn't, but it is, or can be, clever.
Even if locate doesn't directly do what you want, provided that you only need the file name to do whatever it is, you can often do it by feeding the output of locate through, eg, grep to filter the output more, and still be finished before find has really got going.
Is there another omnipresent tool for conditional file search, one that offers as many options as "find", but as fast as "locate"? My Unix Academy training DVD teaches these two, or there's always a trade-off speed vs. flexibility?