Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Finding files with 'locate' UNIX
A while back there was a post regarding using 'find' to locate all non-English .lproj files.

Since then, I still haven't gotten the hang of 'find'. But my find demands are fairly minimal. Even so, it'd be nice to have a simple CL utility for searching. Today I ran across an article at O'Reilly & Assoc. that mentions the program 'locate'. Check out Unix for the Rest of Us for a great overview of the UNIX underpinnings of OS X (on the first page) and a detailed example of using 'locate' on the second page.

[Editor's note: This is an article from June, but it's still quite relevant today, and makes for good reading. Once you understand how locate works, go grab a copy of the freeware program Locator, which wraps a nice Cocoa GUI around the 'locate' command, allowing you to run lightning-fast searches from the GUI. Locator's speed leaves Sherlock in the dust.]
    •    
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)
 
[4,526 views]  

Finding files with 'locate' | 9 comments | Create New Account
Click here to return to the 'Finding files with 'locate'' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
update locate
Authored by: bkitchman on Dec 03, '01 01:09:37PM

Remember to update your locate database by running /usr/libexec/locate.updatedb. I am not in front of my Mac right now so this may not be the correct path, but I believe it is. You may even want to setup a cron job to run the updatedb once a day, otherwise locate will not find new files that you may have added to the system since the last update.



[ Reply to This | # ]
cron jobs
Authored by: seb2 on Dec 03, '01 08:04:12PM

there already *is* a cron job preconfigured in your system. the only problem with that is that it runs once a week in the middle of the night, so if your computer is not running 24/7, the database won't get updated. (the script is /etc/weekly)

a possible solution to this would be to edit your /etc/crontab. there are nice tools out to edit this file from the gui if you don't want to do this from the terminal. look for "cron" on versiontracker. my favorite is "cronnix".

btw, if you have suggestions for "locator", feel free to mail them to me, always glad about suggestions.



[ Reply to This | # ]
Utilities with a GUI
Authored by: nagani on Dec 03, '01 07:19:02PM
The freeware suggested by rob, Locator, will rebuild the locate database for you. It comes with good documentation and nice features: it can index removable media, it can reveal the file in the Finder, or open it, or open a terminal window with the path... You can focus the search to a given directory (oops, I mean folder...)

My favorite feature is that it can display a preview of my pics, even for files bigger than 500kB, as the pre-10.1 Finder did.

Link:http://www.sebastian-krauss.de/locator/

[ Reply to This | # ]

Find for dummies - A reference for the rest of us.
Authored by: Cadre on Dec 03, '01 07:19:49PM

There is a wonderful alias called 'ff' which is aliased to find . -name !:1 -print. Just send it an arguement and it will search all directories downward from where you currently are.



[anna:~] linville% ff display.c
./dev/driftnet-0.1.4/display.c
[anna:~] linville%

Not quite as fast as locate or any of those fancy GUI frontends to locate, but of course, it doesn't work on week old filenames.



[ Reply to This | # ]
Locate versus slocate
Authored by: DeusExMachina on Dec 03, '01 08:56:38PM

Locate saves a ton of time over find provided you're looking for something old enough to be in locate's database. But, it's not secure. Unless I'm mistaken, the 'locate' included in OS X makes a list of files in order to accelerate its searches, but doesn't store the permissions associated with files. This means that, say, your unprivileged guest accounts can determine the contents of directories they would normally not be able to list if they are patient enough.

This might not be a problem for most people (it's not for me, but I'm paranoid :) but if it IS, there is a solution. slocate (secure locate) keeps track of this info in its database so that, say, as a regular user I won't receive search results from root-only directories. It's just as fast (or anyway not enough slower to really notice...) and just a little safer.

Problem is, it's not installed by default, and apparently not in my probably-up-to-date fink list either. But, you can get the source from freshmeat.net (search for slocate, although the package is really called something slightly different) and just compile it with minimal CLI skillz.

Of course, if you do do this, you'll need to muck around in the crontab with a little cut-and-pasting to get slocate called each week/day/hour/second instead of locate, but hey: 3 hours work for an insignificant boost to rational peace of mind? ANYDAY! :)

DeusExMachina
(for whom slocate was the third unix package installed back in the days of the public beta... gfortune was the first, and figlet the second ;)



[ Reply to This | # ]
Locate versus slocate
Authored by: oybobby on Mar 24, '02 07:32:47PM

Hello,

I read your article with great interest, but I'm quite puzzled by it since I've found the opposite to be the case (in terms of locate's ability to find things not owned by its invoker).

Here's the text of an unanswered query I made last week to the OS X list at <macosx-l@sparky.listmoms.net>:

I've come to rely on Locator 0.7, Sebastian.Krauss's delightful GUI to the Unix/Darwin locate database <http://versiontracker.com/moreinfo.fcgi?id=12404&db=mac>.

It's much MUCH faster than Sherlock and offers some other significant benefits, including its function to index removable media. But locate, and therefore Locator, have some shortcomings, chief among them is that it's only as accurate as the timeliness of the database's last update. By default, the locate database gets updated weekly by a cron script, and then only when your computer is still on in the wee, small hours of Monday morning.

I've added a database update task to cron for every other night, so that my locate database is no more than 24 hours out of date.

But I've just discovered that the database doesn't search in my home directory's sub-directories where many of my files are located. This includes my Documents, Mailboxes, and Music folders.

The locate man page says, in part, that the database contains "all files which are publicly accessible."

So... what do we mean by that?

My home directory is set with umask 0755 (readable and searchable by all) and is owned by me (501) and group staff (20).

My ~/Documents directory has umask 0700 (readable and searchable by me) and is owned the same way as my home dir.

I'm fairly confident that these are standard perms.

Am I missing something, or is locate not set up for this useful usage? Must I change my home directory's subdirs to be world searchable, and if so, is that a problem?

Thanks.

Regards,
Maurice



[ Reply to This | # ]
Re: Locate versus slocate
Authored by: sjk on Mar 25, '02 10:27:22PM
/etc/weekly runs /usr/libexec/locate.updatedb as user "nobody" so only filenames within directories nobody can read+search will end up in /var/db/locate.db. If you update the database from Locator it runs locate.updatedb as root and won't be restricted by directory permissions so all (well, nearly all) filenames on your local disk will be in /var/db/locate.db. If you want every user to have the ability to "locate" their own files it's easiest to create the db as root, but that also allows them to "locate" anyone's files. A sysadmin-centric approach is to create /var/db/locate.db as root and make it group-readable for a trusted group, restricting everyone else. This is useful for tracking down files for administrative purposes in a server environment. Implementing a more general, user-specific "locate" scheme is nearly futile without file ownership information in locate.db and only worth attempting if the location of each users' files were regulated (e.g. only under home directories). Better to write a locate-style utility that doesn't rely only on pathnames. Or if you only have a couple users you can create a locate.db for each of them. Sorry for the long post; e-mail me if you want more info.


[ Reply to This | # ]
Changing cmd-F to Locator
Authored by: rharmes on Dec 04, '01 01:45:20PM

Does anyone know how to change cmd-F in the Finder from Sherlock to Locator? I am sick of how slow Sherlock is, and Locator searches at least 10 times faster on my machine.



[ Reply to This | # ]
Combine locate with grep
Authored by: thinkyhead on Dec 04, '01 11:14:30PM
The real magic of locate happens when you pipe the output to grep. You may have noticed that locate matches anything in the full path of the item you're searching for, so you often get too many results. grep makes it easier to whittle down those large sets to find what you really meant to find.

For example, say you want to find a file named "thing" but you don't want all the items that match "thing" in their path. This will limit the results to items that don't have any more slashes after "thing" (case-insensitive, of course):

locate thing | grep -iE thing[^/]*$

I use a script named "ffind" to do this for anything I want to locate. Here it is:

#!/bin/sh
locate $1 | grep -iE /$1[^/]*\$


There are other variations on the same theme. For example if you want an exact match of the filename (still case-insensitive) use this:

locate thing | grep -iE /thing$

[ Reply to This | # ]